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ABSTRACT 



This thesis focuses on the development of a data-driven 
decision support system to assist the Egyptian procurement 
activities in foreign countries. The Egyptian Procurement 
Office in Washington D.C. (POW) is taken as an example to 
apply this research. Two areas of procurement type have been 
examined in POW, the Commercial Procurement and the Govern- 
ment Procurement activities, the later type is based on the 
USA Foreign Military Sales ( FMS ) . s y s t em . The Data Flow Diag- 
ram -technique have been used to analyze the system. PC/FOCUS 
have been used to design a prototype software for the P 0 V/ 
Commercial Procurement subsystem to use in an IBM-XT or I3M- 
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I . INTRODUCTION 



A. OBJECTIVES OF THESIS 

The objectives of this thesis are to analyze the current 
procurement system of the Egyptian Procurement Office in 
Washington D . C . (POW) to determine: 



1. Decision criteria are used to select vendors to 
receive the RFP f s; 

2. The most effective way to monitor and administer 

the contracts ; 

3. The best way to accelerate LOA 1 s process and 

provide the required information in the shortest 
time possible; 

4. The design of a prototype decision support 

database system using PC/FOCUS DBMS on an IBM XT or 
AT computer to replace the current manual POW 

system . 

The development of such a system creates a valuable DSS 
tool, the database, to support the POW. This system may be 
considered as a DSS generator for developing a specific DSS 
to include all functions of POW after getting feedback from 
users . 



B. BACKGROUND 

The strategic policy of the Egyptian Government since 
1973 has been to procure weapons systems and military equip- 
ment from different countries in order to modernize the 
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Egyptian Armed Forces. The Egyptian Armament Authority ( A A ) 
is responsible for the procurement activities from foreign 
countries. To effectively accomplish its job, it has front 
offices in those countries, called Procurement Offices (PO). 
The Procurement Office in Washington (POW) is one of these 
offices. The POW deals with two kinds of procurements , 
commercial procurement of the military items from the open 
market inside the USA, and government procurement from the 
Government of the USA. The POW functions are summarized 
below. 

The following are the POW functions outlines. 

1 . Commercial Procurement 

The POW does the following important functios: (1) 
receives Requests For Proposals (RFP f s) coming f rom AA, (2) 
prepares vendor list of the eligible and suitable vendors to 
receive the RFP T s, (3) calls vendors for bids, (4) receives 
and verifies proposals from vendors and forwards them to A A 
(5) Monitors and administers the active contracts inside the 
USA. 

2 . Government Procurement 

All the requests for purchasing weapons from the USA 
Government must be submitted on a special form called 
Request of Offer and Acceptance; (RO_A). After many procedur- 
es in the USA administration the accepted ROA becomes a 
Letter of Offer and Acceptance (LOA) which is a contract 
between the United States of America and Egypt. The LOA's 
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are prepared in Egypt by the A A and the specialized depart- 
ments according to our -needs and the weapons acquisition 
plan. The POW responsibilities in this kind of procurement 
are: (1) receive all the ROA f s coming from AA and forwards 
them to the USA Security and Assistance Center (USASAC), 
"which is responsible for Foreign Military Sales to alien 
and friendly countries 11 , (2) keep track of all R0A T s status 
sent to USA-SAC until final acceptance as an LOA, and (3) 
receive and process requisitions for Purchasing spare parts 
needed for the weapons already purchased from the USA and in 
the service of Egyptian Armed Forces. 

C. PROBLEMS TO BE SOLVED 

Due to the continued growth of the numbers of RFP f s, 
open contracts, and LOA f s, the current manual system needed 
to be improved to allow better performance of the procure- 
ment process. The following are the major problems with the 
current POW system. 

1 . RFP 1 s Function 

This process requires a great deal of effort to 
effectively decide who are the suitable vendors to receive a 
particular RFP. A pre-selected criterion must be applied for 
each vendor. The growing numbers of RFP T s coming from 
Egypt, the large numbers of vendors available in USA, 
and binding time constraints are all important factors that 
may be causing a delay in this process. 



2 . 



Monitor Open Contracts 



A large number of contracts must be monitored for 
payment, shipment, and training of personnel. Invoices need 
to be verified and payed to prevent problems of missed or 
double payments of some invoices. Different kinds of payment 
and fund sources must be monitored too. The present manual 
system requires significant effort to effectively deal with 
these activities. (About 100 man hours per working day are 
needed to do these activities). 

3 . LO A 1 s Functions 

The USA Foreign Military Sales (FMS) procedures are 
very' conservative and lengthy. The POW acts as a co- 
ordinator between the AA and the USASAC. The POW is 
responsible for keeping track of the status of each LOA 
submitted to USASAC. This process takes a long time to be 
completed (at least two months). Speeding up this process 
requires a good monitoring system to keep track of the LOA’s 
and provide information to both sides in the shortest time 
poss ible . 

D. SCOPE, LIMITATIONS, AND METHODOLOGY 

This thesis concentrates on the first two phases of the 
DSS development life-cycle , ie. systems analysis followed 
by the design of a prototype database for the commercial 
procurement activities of POW. The software utilities of 
PC/FOCUS DBMS will be used to develop the prototype. The 



15 



result of this research may be easily adapted to any 
similar office in other foreign .countries. 

In the analysis phase, Structured Systems Analysis (SSA) 
techniques are used to analyze the POW system. In the design 
phase, software engineering methodology is used to design a 
DSS generator for the commercial procurement function. 
Through the analysis and design phases, the DSS approach is 
used. In Appendix A, we present an overview about the Data 
Flow Diagram conventions. 

E. ORGANIZATION OF THE THESIS 

The thesis is structured as follows: Chapter II 

describes the POW current system. Chapter III describes the 



detailed 


problems 


and 


opportunities 


of the 


c u r r e n t POW 


system. 


Chapter 


IV 


discusses 


the 


software 


requirement 


specifications of 


POW. 


Chapter 


V 


provides 


the software 



design to build the DSS generator, the database system for 
the POW Commercial Procurement System (POWCP). Chapter VI 
presents the conclusions and recommendations of the thesis. 
Appendix A discusses the Data Flow Diagram conventions. 
Appendix B provides the software module listings. Appendix C 
provides the data dictionary of the existing system. 



II. THE CURRENT POW SYSTEM 



A. INTRODUCTION 

This chapter describes in detail the current POW inform- 
ation flow structure. The approach taken for this 
information analysis is to adopt the Data Flow Diagram 
techniques proposed by Gane and Sarson [Ref. j]. A 
comprehensive discussion of this technique is given in 
Appendi x A. 

The POW is the most important procurement office outside 
Egypt , because of the heavy demands of the AA and the 
specialized departments to procure weapons and military 
items from the USA. The primary goal of POW is to provide 
procurement functions from the USA in the most efficient and 
effective ways. Officers from different major forces and 
specialized departments are selected to work in this office 
to deal with the variety of weapons and military items 
required by Egyptian Armed Forces. 

The rest of this chapter describes the organization and 
the major functios of the POW in both commercial and 
government procurement. Data Flow Diagram techniques are 
used to picture the system, the Data Dictionary is used to 



document the system. 



B 



POW ORGANIZATION 



POW consists of the POW Director, POW Director Assistant 
Officers or the Specialized Officers (SO's), Contracting 
Officer (CO), Financial Officer (FO), Shipment Officer 

(SHO), and Administrative Officers (AO), (These abbreviations 
will be used in the DFD and data dictionary.). All officers 
are selected from different Forces of Egyptian Armed Forces 
(EGAF) to represent the major specializations in EGAF. 

1 . Organization Chart 

Figure 2.1 shows the organization of POW. As we can 
see, the POW Director has the overall responsibility for the 
procurement functions inside the USA. The other officers 
a-ssist him in doing his job. The organization consists of 
sections. Five specialized sections represent the major 
topic areas of Egyptian Armed Forces, each one is headed by 
a specialized officer in the particular area. The Administr- 
ation and Control section headed by a qualified officer in 
administration. The Financial and Accounting section headed 
by an officer from the Financial Affairs Authority. The 
Shipment section headed by a qualified officer which is 
responsible for monitoring shipment of contract items to 
Egypt . 

2 . The POW Procurement Responsibilities in USA : 

a. Apply and follow the Egyptian defence procurement 
laws and regulations. 

b. Implement the procurement plan of AA. 
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c. Use funds available in the most effective and 

flexible way. 

d. Assure appropriate contract type. 

e. Reduce the procurement cost and shorten the 

procurement period. 

f. Improve vendor selection function and keep an 

up-todate information about vendors. 

g. Increase competition between vendors. 

h. Develop and use standard operation and support 

systems to perform the procurement function 

effectively. 

i. Monitor shipment of the contract items to the 

country. 

j. Monitor training of personnel associated with the 
contracts . 

The PQW director is responsible for proper execution 
of all the above functions. Figure 2.2 shows all AA requests 
from POW and Figure 2.j shows POW relationships with 
external agencies. 

3 . Job Responsibility of the Specialized Q f f i c e r s ( SO ) : 

a. Apply all the procurement functions as stated in 
I tern 2 . 

b. Follow the orders and directives of the POW 
Dir ec tor . 

c. Check the RFP T s received from AA for proper 
specifications and style before forwarding to 
vendors . 

d. Apply vendor selection rules and criteria to 
achieve full and open competition between vendors. 

e. Maintain fairness and equal opportunity among all 
v'endors by providing them with all information 
•concerning a particular RFP. 

f. Receive and verify proposals for completeness 
before sending them back to AA. 
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g. Check all received payment documents from vendors 
and approve them for payment. 

4 . Job Responsibilities of the Contracting Officer : 

a. Apply Egyptian defence legislation and directives 
related to the procurement process. 

b. Check all contract terms for correctness and 

completeness before signing by POW Director. 

c. Check and review vendor financial status before 
putting them in the vendor list. 

d. Keep track of all open contracts and monitor 
vendor performance in contract implementation. 

e. Prepare a termination notice, if necessary, for 

inactive vendors. 

f . Deal with all problems and complaints from 
v endor s . 

g. Participate in the procurement committees in POW 

and check that all vendors are qualified to attend a 
committee and have all the necessary certificates 
and warranty letters. 

The following sections describe the POW system 

functions. Two types of procurements are exist, the 
commercial procurement and the government procurement. 



C. COMMERCIAL PROCUREMENT FUNCTION 

The commercial procurement function is divided into five 
processes, as shown in the DFD in Figure 2.4. 

1 . RFP 1 s Function 

2 . RFC’s Function 

3. Fund contracts. 

4. Administer contracts 

5. Generate Vendor list 
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Figure 2.1 POW Organization Chart 
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Figure 2.3 POW RELATIONS 
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Each one of the above processes is expanded into 
several other processes in a top down fashion to show more 
details. In each level of details, a walkthrough is present- 
ed to explain each process associated with the DFD. In the 
data dictionary, a detailed description of the processes is 
presented . 

1 . RFP T s Function 

The RFP is the official communication from the 
Government of Egypt to the market. For easy explanation, we 
take a particular RFP and follow its sequence. Figure 2.5 
illustrates this process as a DFD. The process starts when 
a particular Force or Department of EGAF ! s "requester" asks 
the Ministry of Defense (MoD) for funding for certain kinds 
of military items from the USA. After receiving a fund 
letter from MoD, a Committee is designated to prepare the 
RFP. The objective of the RFP is to provide prospective 
vendors with adequate information and guidance, presented in 
a clear and logical manner. Basically, preparation of the 
RFP is a team effort. 

a. Receive RFP by AA 

After final approval of the RFP, the requester 
sends it to AA. Any particular RFP usually contains the 
following information: 

( 1 ) Terms 

(2) Evaluation factors 

(3) Specification 



. 24 



POW DFD Level 0 



D1 i VENDOR LIST FILE 



Vendor dat? 

» 



RFP 



I 



AA 



Proposals 



T 

i 

i 



I 



RFP Monitor Data 

f 



RFP 
I Function 



POW 



Vendor 




iiarp 

^ Propc 


w 



VENDOR 



D2 RFP MPNITOR FILE 



Contract 



RFP Data I 




RFC 



-► 



Cont. lionitor 
(' Data 

T 



1 Appoint 

RFC I 

Function „ Final 



oTBes 

Offers 



VENDOR 



D3 CONT. TO BE FUNDED 



POW 




Vendorff 



Figure 2.4 POW Commercial Procurement Functions 
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(4) Delivery schedule 

(5) Quality assurance 



b . 


Check 


RFP 


in AA 










The 


RFP 


i s 


checked 


against 


the annual 


procurement 


plan 


of 


the 


requester . 


The RFP 


must be clear, 



complete, and consistent with the requirement of procurement 
so that it provides all vendors with the same understanding. 
After checking, the AA sends the RFP to POW. 

c. Check RFP in POW 

Once received by the POW, the RFP is registered 
in the General Log Book by the Adm i n s t e r a t i ve section, and 
then routed to the Specialized Officer in the area, who 
reviews the RFP to be sure that the specifications are clear 
and complete and items are clearly identified. (Figure 2.6) 

d. Select Vendors 

The SO selects vendors who will receive the RFP 
from the vendor lists available in POW, or by using a 
special catalog called the Thomas Register which contains 
most of vendors in the USA. He prepares a list of the 
vendors matched with the RFP item specifications and 
approves it with the POW Director. 

e. Issue RFP 

The necessary number of copies of the RFP is 
prepared and mailed to the selected vendors. First time 
vendors must fillout a special Qualification Form. The 
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Figure 2.5 RFP’s Function 
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Figure 2.6 Prepare and Issue RFP's 
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letter sent to the vendors clarif’ies all the general terms 
and conditions that must be followed by the vendors as well 
as the closing date for receiving the proposals. Sometimes, 
for important RFP f s, a pre-proposal conference may be 
scheduled to allow vendors to clarify sections of the RFP 
they may not fully understand. 

f. Check Incomming Proposals 

SO checks and reviews all incoming proposals. 
Only relevant and complete proposals from qualified vendors 
are sent to Egypt. (Figure 2.7) 

2 • RFC ' s Function 

Sometimes, AA authorizes POW to contract with vend- 
ors. It sends a Request For Contracting (RFC) to POW. The 
RFC must contains all the necessary documents for doing the 
contract process. Two kinds of requests may be received, RFC 
with a specific vendor already selected by AA or a list of 
technically accepted vendors to choose from. The awards are 
generally based on cost. If two vendors have similar cost 
bids, previous contracts with Egypt or the USA Armed Forces 
are considered. The following are the procedures for a 
particular RFC: (Figure 2.8) 

a. The Specialized Officer (SO) 

Receive and review the RFC in the area. The most 
important document received with the RFC is the technical 
evaluation and acceptance of vendors and the best and final 
offers of each vendor. 
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b. The Financial Officer (FO) 

Checks availability of funds for RFC. 

c. The Administrative Officer (AO) 

Prepares the Contracting Implementation Plan 
(CIP) and the meeting schedule with vendor(s). The AO 
informs vendors of the date and time of the negotiation 
meeting. The negotiation period should not exceed two 
weeks . 

d. Vendors Negotiation 

The POW Director designates a team for 
discussions and negotiation with vendors. The team consists 
of members from specialized officers, the contracting 
officer, and the financial officer. The negotiation issues 
are s t r a i gh t f o r wa r d and consist generally of insuring 
competition between vendors and obtaining the best price and 
conditions possible. 

e. Pre-Award Survey 

This servey must be undertaken by the team. The 
factors to be considered for each vendor are: 

(1) adequate financing, 

(2) ability to meet delivery and specifications, 

(3) satisfactory record of performance, 

(4) satisfactory record of integrity, 

(5) necessary organization, and 

(6) necessary facilities and equipment. 
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The contract is awarded to a vendor after analysis 
and calculation of all the above factors. Figure 2.9 shows 
the RFC process and Figur 2.10 shows the contract award 
process . 

f. Team member responsibilities in RFC Process 

(1) Contracting Officer . Prepares the contract 

draft paying special attention to the contract terms and 
conditions . 

(2) Financial Officer . Calculates the amount of 
dollars needed to fund the contract and the initial 
deposits. He also prepare the payment. 

(3) Specialized Officer . Checks all thetechnical 
terms of the contract e.g. item catalog numbers, warranty 
period, inspection plan, technical assistance, training plan. 

(4) Administrative Officer . Collects and keeps all 
documents of the RFC and records all events in a special Log 
Book. 

(5) PQW Director . Checks and approves the contract 
before the final signature, and then invite the selected 
vendor to sign the contract in POW. 

All the contract related documents are collected in 
a file until the implementation phase. A contract monitor 
record is created to keep all active information about the 
contract . 



35 



3. Funding Contracts 
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3 • Fund the Contracts 



Two types of fund source are available: budget and 

loans. Figure 2.11 shows the main process of funding 

contracts. Processing of any procurement activities cannot 
be started unless POW receives the financial letter that 
assigns the money value and the source of funds to be used. 
The preparation of defense budget and loans is beyond the 
scope of POW functions. The POW responsibility is 'to 

effectively manage funds dedicated to new or currently 
active contracts. The cash needed over a period of time must 
be carefully calculated. Monitoring the cash flow and bank 
status is one of POW's major functions. The following are 
the procedure to fund the contracts, 
a. Funding from Budget 

( 1 ) The Needed Documents are (Figure 2.12) : 
FUNDING LETTER--Received from AA. 

LETTER OF CREDIT — Received from the Central 
National Bank of Egypt (CN30EG) amounting to the 
total value of contract and the advance deposit 
to be paid to the vendor. 

LETTER OF G U A R A NT E E -- R e c e i v ed from vendor for 

the security of contract execution from vendor. 

LETTER OF G U A R A NT EE -- R e c e i v ed from vendor for 

the amount of advance deposit he receives after 
signing the contract. 

OTHER DOCUMENTS AND CERTIFICATES — These documents 
are related to the contract e.g. warranty ,• inspec- 
tion, source manufacture certificate etc. 

(2) Open Letter of Credit . Send letter to the 

specified bank to open in favor of the vendor a confirmed 



38 



and irrecoverable letter of credit, in .a prepared form 
letter . 

(3) Activate the Contract . The contract is 
activated and implemented upon the agreement date, 
b. Funding from Loans 

(1) Determine the Source of Fund . The initial 
funding letter with the RFP determines the source of funds 
and whether or not it T s funded from USA loans. POW considers 
that when preparing the vendor list for the RFP. 

(2) Use the Loans . The loans are already 

approved and available for withdrawal. One loan may serve 
many contracts. Loan-based procurements are constrained by 
many factors such as: vendor selection, manufacture product, 

and limited amount of dollars. AA understands these 
constraints and follows its rules accordingly. 

( 3 ) Process Funding from Loans . After finish- 

ing the contracting phase, POW sends a letter to the Defense 
Security and Assistance Agency (DSAA) asking them for 
funding the contract from a loan, (Figure 2.13 ) shows the 

procedures of loan funding. Two documents must be supplied 
with this letter: a copy from the signed contract and the 

Justification Sheet which is prepared by DSAA to 

assist the procurement. The request is processed by DSAA 
and, if accepted, a letter is sent with the Case Designator 
number for the contract, which serves like the credit letter 
from NBOEG in the budget base procurement. POW informs the 
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vendor by that number to start the’ implementation phase of 
the contract . 

4 . Administer Open Contracts 

Each specialized officer is responsible for 
monitoring a group of contracts in his area. The contracts 
are divided into groups according to specialized areas. The 
major functions of contract adm i n i s t r a t i on s are shown in 
Figure 2.14. The following are the description of each 

function . 

a . Payment 

Much effort and time are needed to do this- 

function. The following are the payment procedures as 
presented in Figure 2.15= 

( 1 ) Receive the Payment Document . P 0 V/ 

receives the payment documents from vendors which 

include: The original invoice, the original receipt from 

Freight Forwarder (FF), who is responsible for shipment of 
items related to contracts, and the original certificate of 
origin for the items. 

(2) Register the Payment Document . All 

incoming documents must be register in the central register 
book and routed to the responsible specialized officer (SO). 

(3) Checks the Payment Document by SO . The SO 

checks the document with the contract monitor file to ensure 

that all the documents are original and correct. He 
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compares the invoice with the shipment notice from FF to see 
that they match. He checks the previous payment documents to 
make sure there is no duplication. He then approves the 
payment from the technical point of view and routes the 
payment documents to the Financial Officer (FO). 

(4) Check the Documents by FQ . The FO checks 
the invoice amount, the source of funds, the previous 
payments, and the approval of the SO. He prepares the check 
or the money order and approves the payment from the POW 
Di rec tor . 

b. Monitor Personnel Training 

Figure 2.16 shows the training procedures. The 
training may be done in Egypt or in vendor training center 
in USA. In' the first case, the vendor must inform the POW at 
least two months before the training date of the names of 
expertise who will train our personnel. A special enquiry 
form is sent to the vendor to supply this expertise 
information. The second case, when training must be done in 
USA, vendor must inform POW six month before the training 
date of the date, duration, and locations of the training 
center, and the number of personnel who will train. 

c. Monitor Shipment of Items to the Country 

A Freight Forwarder (FF) company is contracted 
to do the shipment of all items related to contracts. This 
company is responsible for safe and timely t r a n s p o r t a t i o n of 
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contracts items to Egypt, It keeps all the documents and 
information related to the contents of packages delivered 
from all vendors to the front door of the FF company. Figure 
2.17 shows the shipment main functions. The shipment officer 
sets the priority of shipment to the country according to AA 
demands and informs FF to take the necessary actions. The 
normal shipment is done by the FF, The shipment officer 
receives a weekly progress report from FF. This report 
contains the quantity shipped during the week and the 
inventory level inside the FF store and any problems to be 
solved. FF receives the delivered items from the vendor and 
signs a receipt to the vendor. This receipt must be included 
with the payment document when delivered to POW. 

POW is equipped by a computer terminal connected 
to the FF computer center to access the information about 
the shipping status and the inventory level, 
d. Reporting 

In general, the POW is the information link 
between AA and USA government and market. Good communication 
between POW and AA is essential to properly accomplish the 
procurement function. Reports can be classified under the 
following kinds of categories (Figure 2.18): status 

reports, analysis reports, progress reports , comparison 
reports, evaluation reports , technical reports, market 
research report, etc. In the next chapter we present details 
of all reports used and needed by POW. 
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4.3 Monitor Shipment 
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5. 



Generate Vend or List 



The procurement function in the USA must be based on 

competition between vendors. The Manual of Acquisition 

Topics in the Navy Acquisitions [Ref. 5], states: 

Competition received widespread attention during 1984. 
President Reagan stated that competition " is the single 
most important source of innovation, efficiency and 
growth in our economy. 

Rear Admiral Giordano, SC,USN, Chief of the Supply 

Corps, further stated that: [Ref. 5] 

Competition makes- good business sense, and I want to 
make it clear that increasing competition must be a 
primary objective of all personnel involved in logistics 
management . 

Commodore Stuart F. Platt, SC, USN, as the first 

Competition Advocate General (CAG) of the Navy. He stated: 

Competitive procurement represents the extension of the 
principle of fairness into the defense acquisition 
process. The public trust placed in those who obligate 
public funds includes the assurance that a fair 
opportunity will be provided to all who can meet the 
government’s needs. One effective way to significantly 
reduce costs, and thereby be able to afford our defense 
r e qu i r erne n t s , is to increase the use of competition. 

The navy is now emphasizing competitive procurement 
st rongl y . 

POW should apply the competitive procurement as well 
Figure 2.19 shows the Vendor List source schema and Figure 
2.20 shows the main processes of generating the Vendor List. 
Building and maintain a good database about vendors is 
essential. We call it the vendor list in the manual system. 
Bad selection of vendors may seriously affect our Armed 
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Figure 2.19 Vendors Source Schema 
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Figure 2.20 Generate Vendor List 
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Forces. A number of different factors can be measured to 

provide a basis for evaluating vendors. However, depending 
on the type of military items to be purchased and the past 
experience, factors may vary in their degree of importance. 

Any new vendor to POW must pass through extensive 
investigation to be sure that they have the qu a 1 i f i c a t i o n s 
to be included in our vendor list. Figure 2.21 shows the 
procedures of evaluating new vendors. The following factors 
are taken into co n s i d e r a t i on when evaluating vendors: 
(Figure 2.21) 

Business Assets Value (BAV) 

Business Start Date (BSD) 

Source Man u f a c t u r e r , Distributor, or Broker 

Quality 

Supplier to USA Ar my / N a v y/ A i r Force 

Level of Satisfaction of Previous Contracts 

Business Activity (BA) 

After recording the above information in a 
Qualification Form, POW validates this information by 

asking a market research and consumer association to assess 
the financial capability of the vendor. This validation is 
always done for a new vendor or in Pre-Award Surveys. The 
following are some quantitative and qualitative Figures that 
should be considered to review vendor status. 
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a. Quantitative Items 
Trends in : 

Gross margin ratio 
- Sales 

Debt/equity ratio 
Return on investment 
Cash flow/debt 
Working capital needs 
Cur rent ratio 

account r ec e i v ab 1 e / pa y a b 1 e turnover 
Inventory turnover 

b. Qualitative Items: 

Credit ratings 

Notes to financial' statements 

Market share 

Capital asset stability 

The type of evaluation required to determine vendor 
capability varies with the nature, complexity, and dollar 
value of the purchase to be made, 

POW is responsible for processing only the proposals of 
qualified vendors. The first filter to catch the non- 

qualified vendors is during the RFP process. The second 
filter is during checking and verification of new vendors, 
and the third filter is during the Pre-Award Survey. 
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D. GOVERNMENT PROCUREMENT 

1 . Foreign Military Sales ( FMS ) 

a. Background 

The United States has been assisting friendly 
countries in establishing adequate defensive forces for 
their national security and for resisting external 
aggression. This policy is essential to the security of the 
U-S A itself. 

b. FMS Important Issues: 

(1) No commercial export license may be issued for the 
sale of major defense equipment valued at $25 
million or more, except through an FMS case. 

(2) The President of the USA, 30 days prior to giving 

his consent for sales, must submit to the Speaker of 
the House of Representatives and Committee on 
Foreign Relations of the Senate , a written 

certification of the proposed arms sale. The 

Congress may veto this proposed transfer. Further- 
more, the certification submitted to the Congress 
shall be unclassified (classified information 
submitted separately) to permit public disclosure. 

(j) The cost and interest to be charged to the foreign 
country will include administrative services, plane 
and production equipment cost, and a proport ionate 
amount of any nonrecurring cost of R & D. 

(4) Commercial sales, through export licenses ,of major 
defense systems are limited of the value of $25 
millions . [Ref. 6 ] 

c. FMS Authority Distribution 

Figure 2.22 shows the inter-rela t ions between 
the USA authority in FMS. The following are the role of the 
main USA authoroties envolved in this system. 
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(1) Congress . ' Their are various laws for the 



purpose of guiding and controlling the FMS process. One of 
the key laws is that the President of the United States must 
submit to the Congress, 30 days prior to his consent, every 
proposed sale that exceeds $25 million. Moreover, the 
Congress requires annual reports from the President on the 
status of FMS [Ref. 14], 

(2) State Department . The State Department is 
primarily concerned with U.S. security policy all over the 
world, and so established the Bureau of Politics - Military 
Assistance [Ref. 7]. This Bureau generates policy guidance 
and procedures concerning the issues of USA security, FMS 
and arms control. Within the bureau their are three offices 
that maintain constant contact with the DoD and other 
departments as necessary for the approval of military 
exports. The three offices are: 

Office of Security Assistance and Sales (SAS) 

Office of Munitions Control (OMC) 

Office of Planning and Analysis for International 
Security . 

(3) Department Of Commerce . The Department of 
Commerce is primarily responsible for the overall economic 
growth and technical development of the USA. Within the 
department, the office that maintains inter-departmental 
discussions affecting the international trade is the office 
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of Domestic and Business Administration (DIBA).This office 



is concerned especially with: [Ref. 14] 

Competitive assessment of US industry in domestic 
and world markets. 

Expansion of export and export control 

administration . 

Federal recognition and participation in inter- 
national exposition and trade fairs. 

s 

(4) Department of Treasury . The Department of 
Treasury, in the area of foreign trade, participates in the 
financial negotiations between the US and foreign countries. 
It exercises broad control over military and commercial 
export programs, assuring that they are compatible with 
the US trade and security policy. It also reviews trade 
agreements for credit risk evaluation, assuring the best 
utilization of US Government backing to credit institutions 
[Ref. 21 ] . 

(5) Department of Defense (DoD) . The DoD is 

the principal actor involved in FMS. The Do D serves as the 
main co-ordinator for all the objectives of the other 
departments concerning FMS. There are four major offices 
involved in military assistance and/or the sale of military 
items: [Ref. 14] 

- Defense Security Assistance Agency (DSAA) DSAA 

Serves within the DoD as the responsible office for 
Government to Government FMS, performed under the control of 
the Secretary of Defense. It was established in 1971 and has 
been responsible since then for the generation, and 
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maintenance of procedural guidance according to the 
Military Assistance and Sales Manual, DoD Manual 5 1 0 5 . 3 8 - M 
[Ref. 7J. In addition to participation in top level 
planning, programming, and reviewing of FMS. DSAA performs 
the following functions: [Ref. 7] 

* Conducting negotiations with the customers. 

* Interfacing with and assisting US industry, in 
its effort to receive export licenses from the 
State Department for doing business with foreign 
countries . 

* Managing FMS credit arrangement and guarantees 
of private financing of FMS. 

Office of Assistance Secretary of Defense for 
International Security Affairs (QASD/ISA) . The OASD (ISA) 
develops policies concerning international security through 
a mutual agreement with the State Department. Within ISA the 
Deputy Assistance Secretaries (Regional desks), provide and 
prepare for their regions a threat analysis for a specific 
country based upon its potential enemies and the military 
capabilities of both sides. The Director of Strategic Trade 
and Disclosure within ISA provides official DoD positions 
on any proposed military or commercial exports that has 
possible military application. This is accomplished in 
coordination with Department of Commerce and the State 
Department. The review of any export license is done by the 
Inter-agency Board consisting of r e p r e s e n t a t i v e s from the 
Department of State, Department of Commerce, Department of 
Treasury and the Director of Strategic Trade and Disclosure. 
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Elements of the Armed Forces and JCS. The State 



Department’s Office of Munitions Control (OMC), submits the 
export application of the foreign country to the concerned 
service Army (Director of International Logistic), Navy 
(Security Assistance and Sales). Each service has major 
functions to achieve related to FMS: [Ref. 14] 

* Upon receipt of the export application, through 
the DoD Director of Strategic Trade and 
Disclosure, it formalizes and presents its 
position . 

* It provides the detailed analysis and evalua- 
tions that are necessary for the negotiation 
process . 

* It assists DSAA in the process of the 

negotiations . 

* It manages and administrates the sales activity 
during its performance. 

2 . Egyptian Government Procurement from USA 

The major two kinds of military procurement from the 
USA are the Government procurement of Major Defense Items 
and the Spare Parts Procurement for Weapons already in 
service and purchased from the USA. Both kinds of procure- 

ment must be processed according to the USA FMS rules and 
regulations. Major defence items procurement such as 
aircraft, tanks, and air defense weapons is lengthy 

procedure. POW must be alert and responsive to speed up this 
process during its performance. 

The POW acts as a co-ordinator between AA and the 
USA Security Assistance Center (SAC), which is the 
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responsible organization inside the USA Government for 
administrating the requests of friendly foreign countries to 
purchase major defence items and military equipment. The FMS 
policy procedures must be well understood to speed up this 
kind of procurement. A network of interrelation 

r es p o n s i b i 1 i t i es starting from the President of USA, 

Congress, Department of State, Department of Treasury, 

Department of Commerce, and Department of Defense are all 
involved in processing the requests of major defence items 
purchases. Many factors must be considered in doing this 
kind . of procurement. The political issues also have a great 
effect on this kind of procurement. 

The following details the steps in the two kinds of 
Government procurement. (Figure 2.23) 

a. Major Weapons Systems Procurement Steps 

The basic document in this kind of procurement 
is the Letter of Offer and Acceptance (LOA) ( DD FORM 1513). 
The LOA is also known as a "Request Of Sale" or "Request 
For Price and Availability". After the acceptance of the 
LOA by the USA Government, it becomes a contract between the 
two countries. The Government procurement consists of eight 
steps initiated by submitting the Request for Letter of 
Offer (RLO). All USA Forces have similar procedures for the 
FMS. The following procedures are based on the Air Force FMS 
(U.S. Department of the Air Force, " logistics - Foreign 
Military Sales" AFM 400-3, 17 Feb 1976), [Ref. 6J. 
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Figure 2.23 Organizational Structure for Receiving and Processing a 
Request for Offer and Acceptance [Ref. 21] 
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The RLO must be prepared and reviewed very 
carefully by the Top Level in Egyptian Minister of Defense 
(MoD), AA , and the Major Armed Forces, A special Forms of 
RLO must be prepared known as a ” Checklist for weapons 
system sale request. 

The following are example of the USA Air Force Checklist 

Main sub j ects : 

* Country 

* Aircraft Mo d e 1 / De s i gn a t o r / Se r i e s / (MDS) 

* Quantity 

* Basic Co n f i gu r a t i o n 

* Source Data 

* Delivery Data 

* Missiles/ECM Pods/Bombs/Ammo 

* Anticipated LOA Acceptance 

* Operational Concepts 

* Maintenance Concepts 

* Supply Concepts 

* Contractor Engineering and Technical Services (CETS) 

* Weapons Systems Logistics Officers (WSLO)/System 

* Acquisition Officer (SAG) 

* Training Concept 

* Insurance 

* Quality Assurance 

* Other Pertinent Remarks 

SOURCE of this checklist is: AFM 40G-3(R), Attachment d, 

17 -February 1976. 

Negotiations and discussions are held between 
the repr esentati ves of the two countries to clarify the 
requirements of Egyptian Armed Forces and the assessments 
for the acquisition request. The POW Chief officer particip 
ates in these meetings. 

The final form of the RLO is submitted to the 
Defense Security Assistance Agency (DSAA). 
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The following are the steps for procuring the 
major Defence Items: 

(1) Submit the RLQ to DSAA . The DSA A requests 
the Related H.Q. for its position on the request. 

( 2 ) Assign Case Designator and Request Price 
and Availability . POW receives acknowledgment of receipt 
from the related H.Q., at the same time the H.Q. asks the 
Various commands for their Price and Availability (P & A). 
[Ref. 6 ] . 

( 3 ) Determination of P & A and Submission to 

the .related H.Q. The various commands prepare the P & A 

within JO days and submit it to the H.Q. 

( 4 ) Preparation of the Offer and Acceptance . 
Upon receipt the P & A from the various commands of the 
related H.Q. prepares the complete LOA. Any LOA in excess 
of $25 million or sales of major defense item in excess of 
$7 million must be submitted to the director, DSAA, who in 
turn must notify the Congress. If the Congress does not 
adopt a concurrent resolution objecting to the sale within 
30 days, the DSAA authorizes the H.Q. to sign and issue the 
LOA to the requesting country [Ref. 7J. 

( 5 ) Review, Acceptance and Funding of the Offer 
and Acceptance . POW receives the LOA and sends it to AA for 
reviewing which must sign it within 30 days from the date of 
receiving the offer. If AA accepts the offer, the signed LOA 
is returned to the POW who in turn sends it to the DSAA. 



(6) Provide Case Directive . Upon receipt of 



the acceptance of the L 0 A , the H . Q . issues case directives 
to the participating Major Commands and implementing 
agencies. The case directives include: [Ref. 7] 

Financial aid 
Delivery term code 

Force Activity Designator (FAD) or priority 
Purchaser's service code 
Nonrecurring cost 
Asset use charge 

Sales commissions and contingent fees 
Any special instructions 

( 7 ) Furnish Material or Services and Notify 
therelated Force accounting And Finance Center . (Air Force 
Example ) The major commands and the implementing agencies 
that take actions based on the regulations in AFM 400-j are 
[Ref. 6]: 

Air Forces System Commands (AFSC) 

Air Force Logistics Command (AFCTC) 

Air Force Training Command (AFTC) 

Tactical Air Command (TAC) 

Air Force Accounting and Finance Center (AFAFC) 

Following these actions, procurement and 
budget authorizations are obtained. 

(8) Billing the Customer . This is the last 
step in the processing of the foreign military sales, 
concerning the billing and terms of payment's . Like the 
commercial procurement, there are two sources of funding the 
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government procurement: Budget and Loans. The procedure for 

payment is very similar to the commercial procurement. 



Conclusion . The FMS procedures are complex and 
lengthy but nevertheless logical and structured. The 
Congress has full control over the procurement requests 
which exceed $ 25 million or for Major Defense items that 

exceed- $7 million. 

DoD implements the FMS through major services using the 
LOA D.D. Form 1513 as a contract document between the USA 
and the foreign country. This document specifies the terms 
and obligations concerning the two governments in processing 
and implementing the procurement system, 
b. Spare Parts Procurement 

This kind of procurement is oriented towards 
weapons already purchased and in the service of the Egyptian 
Armed Forces. The FMS system for this kind of procurement 

is divided into two parts: FMS1 and FMS2 

(1) FMS 1 . Represents an amount of money paid 

by the Egyptian Government to participate in sharing the 
cost of the inventory of spare parts to serve all countries 
which have purchased weapons from USA. The FMS1 system keeps 
track of inventory of all kinds of spare parts ready on the 
shelf to serve all participating countries. It uses advanced 
scientific technique to prevent any shortage of spare parts. 

(2) FMS2 . Represents an amount of money to 

cover the yearly requisitions of the spare parts needed by 
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the EGAF 1 s • 



Requisitions from the system may be done on a 



daily basis in a precisely structured computer format that 
allow processing of every single item separately, POW has 
nothing to do with the implementation of the system, except 
receiving and sending any related system documents to both 
sides. Charges to the system are done by the POW upon 
receipt of an authorized payment letter from the AA. 
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III. PROBLEMS AND OPPORTUNITIES IN 



THE POW CURRENT SYSTEM 



A. INTRODUCTION 

This Chapter identifies the problems and opportunities 
of the POW relevent to developing a data driven DSS. In the 
problem part, we address the system wide problems first and 
then describe any problems in each particular function, if 
any. In the op p o r t u n i t i e s part of this section, we describe 
in some details what computers and databases can do for 
improving the existing functions of the POW current system. 
It should be noted that the solutions for all of these 
problems will not be covered in this research because of the 
time constraint; rather we will emphasize the detailed 
design of the commercial procurement functions . The inten- 
tion is to present all the problems and opportunities of the 
POW uncovered during interviews with the POW specialized 
officers. 

B. SYSTEM WIDE PROBLEMS 

The POW is the central point of receiving all the 
requests of EGAF’s for procurement of military items and 
weapon systems from the USA. Because of continued increasing 
demands from the USA, the workload in POW is now increasing 
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exponentially. The system is designed to deal with much 
smaller demand than currently exists. 

The existing manual system needs to be developed and 
supported by computer tools to enhance its capability. The 
system wide problems with the manual system are: 

1. Too much effort and time needed for the manual 
tasks . 

2. Some functions cannot be done in a reasonable length 
of time . 

3. Generating status reports is getting more difficult 
without computer tools. 

We follow exactly the structure of Chapter. II to 
describe the problems and opportunities of each system 
function presented in that chapter. 

C. COMMERCIAL PROCUREMENT FUNCTIONS 

1 . RFP ' s Function 
a * Problems 

Too much effort and time needed for the prepara- 
tion of vendor list for a particular RFP. 
b . Causes : 

(1) Large number of RFP T s 

(2) The RFP received is not in a standard format to 
allow easy accessing to the vendor data. 

(3) Large number of vendors available in USA to select 
f r om . 



69 



c 



Opportunity 



Building a database for vendor information 
allows better processing of the RFP’s and decrease the 
vendor selection time for a particular RFP. 

2 . RFC Function 
a. Problems 

No problems are addressed in this function, 
c. Opportunity 

. A DSS can be used as a tool for evaluating 
proposals and vendor selection. The guidelines to the system 
are: 

(1) Multiple evaluation factors are established and 
weighted. 

(2) Each proposal is scored by the technical committee 
using these factors . 

(3) The system should allow presentation of information 
to the evaluators in different formats including 
graphs and utility analysis. 

3 . Fund the contracts : 

This part include the both budget and loan funding. 

a. Problems: 

Too much effort needed to manage the funding 

functions . 

b . Causes: 

(1) All contracts with vendors in USA must be funded via 
POW, a large volume needs to be funded, over 500 
contracts . 

(2) Monitor all credit and guarantee letters associated 
with contracts; it represents large volume, over 
1500 of different letters with different banks and 
different vendors interacting in this process. 
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Opportuni ty ; 



c • 

(1) This process has a potential for automation. An 
automated system will allow better control of this 
process by producing status reports of all tne 
credit and guarantee letters . Warning reports can 
be produced for renewal validity dates of the 
guarantee letters 

(2) Establish Financial management system to monitor 
funds from loans, especially unused loans which may 
have a limited time of validity. Effective use of 
funds from loans depends on timely decisions 
concerning use of this fund. The decision process 
related to the effective use of available loans is 
very important to the EGAF * s . POW, as a front office 
can assist the AA by producing status and comparison 
reports of the fund availability from loans. Passing 
this information to AA ahead of time to take the 
necessary actions before the end of validity date is 
very important. This one benefit of the system may 
cover many times the cost of building the system. 

4 . Administer open contracts 



a. Problems 

All the problems of any manual system are 
figured in this system to some degree or another. High 
volume of paper work, slow, data redundancy , spending more 
time and effort to do the function, etc. 

b . Causes 

The problems in this function are due to the 
fact, that the manual system lacks the capability of the 
computer system with respect to the routine and repetitive 
work. The POW staff tries to keep the system running by 
spending more effort and time. The four s u b- f u n c t i o n s of the 
open contract adm i n s t r a t i on , payment, shipment monitoring 
personnel training, and reporting form four sub-systems 
which have a great potential for automation. 
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c. Opportunity 



(1) Payment . The payment process involves the 
technical and financial checking and validation based on the 
contract, invoice, shipment receipt, necessary certificates, 
vendor performance etc. Everything must be checked before 
payment is made. To speed up the decision related to this 
function, a computer tool is a must. By developing such a 
system, the specialized officer can easily validate the 
payment documents. In the design chapter we present a 
proposed system for these functions. 

( 2 ) Monitor Shipment of Items to the Country . 
POW has an access terminal to the Freight Forwarder 
computer. This system can be improved by allowing transfer 
of the summary data about the shipment status to the FOCUS 
database. This function is included in this research and may 
be expanded later. 

(3) Monitor Personnel Training . A considerable 
amount of work needs to be done by the POW to monitor the 
training of personnel. All open contracts, commercial or 
government procurement, have a training part which needs to 
be scheduled on time. POW must inform AA ahead of time of 
the training plan associated with each contract to have 
enough time for selecting and preparing personnel who will 
attend the training programs in the USA. On the other hand, 
all personnel affairs in the USA are the responsibility of 
POW e.g. monthly salary, traveling reservation and tickets, 
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and medical. This function can also be automated. The 



database allows easy system development of such functions to 
monitor and control all training in USA. 

(4) Reporting . A database system is a powerful 
tool for generating different kinds of reports. In PC/FOCUS, 
the reporting facility is excellent. It allows user to 
generate any kinds of reports they need from the database in 
seconds without programming. The reporting and graphics 
facilities in PC/FOCUS provide a valuable DSS tool for 
presentation of information. 

5 . Generate Vendor List 

This function is necessary for the RFP ! s function.’ 
We separate it here because of its special importance. We 
have to deal only with potential vendors in the USA 
industry. 

a. Problems 

The manual vendor list is time consuming, for 
example, 135,000 US manufactures are exist in Thomas 
Register, over 500 vendors have contracts with POW. 

b . Causes 

Many sources are used to generate a vendor list: 
vendors who already have contracts with POW, vendors suggest- 
ed by AA for a particular RFP, vendors responding to an 
advertisment in the newspaper, vendors responding to RFP's, 
vendors supplier to the USA Ar my/ Na v y / A i r Force, and vendors 
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from Thomas Register catalog. The investigation process 
requires much time to check the Qualification Form and 
verify it from market research associations, 
c . Oppor tuni ty 

The potential for automation is very high. 

Putting vendor information in a database is essential for 
the POW function. The cost of selecting bad vendors is much 
higher than the expected cost to develop any system to keep 
and maintain information about vendors. POW has a major 
responsibility in selecting and validating vendors before 
passing their proposals to AA , even those suggested by the 
AA with a particular RFP. vendor selection criteria, must be 
applied in all the procurement phases. Creating a database 
for vendors will allow the specialized officer to prepare 
the vendor list in a fraction of time needed for the manual 
system . 

D. GOVERNMENT PROCUREMENT 

As we mentioned in describing this process, POW acts as 
a co-ordinator between AA and USA administration. 

1 . Procurement steps for the major Weapons system The 
Government procurement cycle is mainly done inside the AA 
and the USA administration. POW serves essentially as a 
communication link between the two. 
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a . Problems : 

(1) How to speed up the process from submitting the RLO 
• until we get the LOA ? 

(2) How to monitor the performance of the Egyptian Major 
Weapons System Contracts (EGWSC) managed by the USA? 

b . Causes : 

(1) The FMS procedures are complex. 

(2) A network of i n t e r r e 1 a t i o n s h i ps are involved in the 

FMS process including the President of USA, 

Congress, and many Departments. 

(j) Inside DoD, many H.Q. commands are involved in 
processing a particular RLO. Many rules and 

procedures must be followed. 

c. Opportunity 

Weapons Acquisition is very critical function to 

Egypt. Getting the necessary defense weapons is of vital 

importance. The time to process the RLO is far toolong. 
Monitoring implementation of weapons system projects is very 
important. Building a decision support and monitoring 

system will be of a great help in answering the above two 
questions. POW is the most suitable organization to do this 

function, because of its position as a co-ordinator or link 
between the EGAF 1 s and the USA administration. Two database 
may be needed, one for the acquisition phase i.e. the 
activities starting from submitting the RLA until getting 
the LOA. The other is for the implementation phase to 

monitor all the current projects managed by USA administra- 
tion for the benefit of Egypt. These two sub-systems will 
be of great help in speeding up the acquisition process by 
pointing up any delay, and by providing the data needed by 
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USA rapidly. By building an information system to monitor 
Government procurement from USA, we put a foundation of the 
DSS in the Weapons Acquisition System (WAS), itself. 

Knowing the FMS policy and procedures are very important in 
building this system. All the technical References related 
to the FMS system must be available. Technical support from 
USA may be needed to build that system. 

2 . Spare Parts Procurement 

No Problems and Opportunities related to POW are 
perceived by the author in this study. 
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•IV. SOFTWARE REQUIREMENT SPECIFICATION OF POW 



A. INTRODUCTION 

The objective of this chapter is to analyze the informa- 
tion flow as presented in chapter II, and create the soft- 
ware requirement specifications for the POW Commercial Procu- 
rement (POWCP) system. The specification presented in this 
chapter will emphasize on the creation of the DSS generator 
for the POWCP database. 

The DSS generator is a set of of interpreters and data 
creation utilities. DSS tools are used to build and 
modify the interpreters. [Ref. 1] 

B. REQUIREMENT ANALYISIS OF POWCP PROPOSED SYSTEM 

The following are the primary objectives of the POWCP 
proposed system : 

Increase functional performance efficiency of the 

POWCP system. 

Assist decision making process in the POWCP system. 

We recognized from chapter II and chapter III that the 

POWCP has a high-payoff area for decision support. To 

capture the benefits of this high-payoff, we are going to 

use the Iterative Design approach ’Staged Development’ for 

building a prototype DSS for the POWCP. The following are 

the expalanation of the approach as presented in [Ref. 1 J : 

DSS need to be built with short, rapid feedback from 
users to ensure that development is proceeding correctly. 
They must be developed to permit changes quickly and 
easily. The result is that the most important four steps 
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in the typical systems development process (analysis, 
design, construction, implementation) are combined into 
a single step which is iteratively repeated. The essence 
of the approach is that the user and the builder agree 

on a small but significant problem, then design and 

develop an initial system to support the decision making 
that it requires. After a short period of use (a few 
weeks), the system is evaluated, modified, and 
incrementally expanded. This cycle is repeated three to 
six times over the course of few months until a 

relatively stable system is evolved which support 

decision making for a cluster of tasks. The word 

relatively is important, because although the frequency 
and extent of changes will decrease, it will never be 
stable. The system will always be changing, not as 
necessary evil, but as a conscious strategy on the part 
of user and builder. 

The advantages of using this approach are: Leads to 

development of DSS Generator, gives early success and 

visibilty, Allows overlapping of different staged DSS 
and integration between them, ability to assimilate 

evolving technology. [Ref. 1] 

To realize the benefits of this approach, we must be 
concerned about the time of development. It should be as 
short as possible (2-3 months maximum for the first version) 
prepare an action plan, for development, divided into phases, 
build the DSS generator, use the structure approach in 
analysis and design of DSS to be able to maintain and adapt 
the system during each stage, finally we should use available 
software as we did in PC/FOCUS. 

The approach used to describe the proposed system is to 
follow the logical sequence for each function and describe 
each process associated with the improved DFD. The secondary 
process for a particular function is described at the end of 
the function. Because our priority is to build the DSS 
generator first, i.e. the database, we first apply the data 
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analysis technique (See data dictionary section, chpter V . ) 
to derive the database structure in third normal form before 
designing the database file as described in the following 
chapter. The disk media symbol used to indicate the proposed 
database files. Only the functions or processes to be 
automated are explained in the following sections. 

1. RFP Functions Description . The fuction is divided 
into sub-fuctions and process, expalanation of each one are 
presented as necessary . 

Process 1.1 : Prepare & issue the RFP . Figure 4.2 
shows the. details of the process. 

Procsess 1 .1.1 Receive & review the RFP . Figure 4.j 
shows the premitive level of DFD. The following are a walk- 
through for each process. The same sequence of will be used 
to explaine the other functions 

Process 1 . 1 . 1 . 1 Register RF P . The purpose of this 

function is to register each particular RFP in the General 
Log Book (GLB)and the RFP Control Book (RFPCB). he code 
used to register the RFP, or any incoming documents to P 0 W 
consists of a six digit serial number starting at one at the 
beginning of the year and incremented by one for each 
incoming document. This number will be used as a key when 
recording the information about the major documents received 
or issued from POW. The information items kept in the GLB 
are: 

* Registration Number * Date Received 

* Source and subject 



79 



r 



RFP's Function 



"\ 




Proposals 



r 






RFP 



RFP & Letter 



Prepare & 
Issue 
the RFP 



POW 



r— i 



“•Names & 
Address 



D3 



VENDOR DATABASE 



Q 



Summary 

Data 



07 



RFP'S MONITOR FILE 



Date 

send 



1 .2 



Receive 
Proposals f** - 




Proposal 



VENDOR, 



Proposals 






POW 






Figured. 1 RFP's Function 



80 



r 



1.1 Prepare and Issue the RFP 
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T he RF? is then routed to the Specialized Officer 
(SO) in the area of specialization. 

Process 1 . 1 . 1 . 2 Review and Checks RFP . The SO 

reviews and checks the specification. This process is 
subjective and relies on the capabilities of the SO. 

Process 1.1. 1.3 Enter RFP in the Database . Enter 

the RFP data in the database through screens. The following 
are the data related to a typical RFP: 

* RFP Number 

* Received date 

* Requester (Force or Department) 

* RFP subject 

* Items needed 

* Item description 

* Unit of Issue 

* Quantity 

* Estimated Dollars value 

* Terms and conditions 

* Vendors who receive the RFP 

* Vendors who send Proposals data. 

(Normalization of data will be done in next chapter.) 

Proc ess 1.1.2 Select Vendors to Receive RFP . 

Selection of vendors to receive the RFP are done only from 
the qualified vendor in the Vendor Database. Creation of the 
vendor database is described at the end of this section. 
(Figure 4.4) 
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Process 1 . 1 . 2 . 1 



Match Item Classes, 



Match a 



particular RFP f s item classes with the item classes in the 
vendor database. This process is done by the computer to 
produce a primary list of vendors who are relevant to the 
RFP. The SO may repeat this process using other item classes 
until he is satisfied with the vendor list produced. The 
vendor list may look as follows: 



RFP-NO 



VENDOR LIST 



VENDOR VENDOR POINT OF VENDOR PHONE ITEM 

ID NAME CONTACT ADDRESS NO CLASS 



Process 1 , 1 . 2 . 2 Check Vendor Details . The SO may 

wish to access the detailed data about a particular vendor. 
He can do that by retrieving the vendor record using the 
vendor ID. If he wants more details about the vendor company 
such as its profile or brand names etc., he may refer to the 
Thomas Register or any other reference. 

Process 1 . 1 . 2 . 3 Approve the Final Vendor List . 

The SO f s must approve all vendor lists generated by any 
means (computer or manual) from the POW Director before 
mailing it to vendors with the RFP copies. 



85 



Process 1.1.3 Mail RFP to Vendors 



Process 1 ♦ 1 . 3 . 1 Produce Vendor Mailing List . 

This process may be done either manually or by computer to 
prepare the mailing label of vendor address and point of 
contact. (Figure 4.5) 

Process 1 ♦ 1 ♦ 3 ♦ 2 Issue the RFP to Vendors. A 



number 


of copies of the 


RFP 


are 


produced 


using electronic 


copier 


machine and 


mailed 


to 


the 


vendors . 


The information 


about 


vendors who 


get the 


RFP 


i s 


recorded 


in the computer 


and the RFPCB, The 


following 


i s 


the data 


structure of the 


RFPCB 


to be r ecorded : 













* RFP Number 

* RFP Copy Number (a serial number within RFP 

* Vendor ID 

* Vendor Name 

* Date of Issue to Vendors 

- Process 1.2 Receive Proposals . 

Process 1.2.1 Receive and Record Proposals . 

Process 1 ♦ 2 . 1 . 1 Register Proposals . All incoming 

proposals are registered in the GLB and RFPCB. A register 
number is given to each proposal in the GLB. The data 
elements to be recorded are: 

* RFP Number * Proposals Serial Number 

* Vendor Name * Date of Received 

* Proposals description 
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1.1.3 Hail RFP to Vendors 
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Figure 4.5 Mail RFP to Qualified Vendors 
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Process 1.2. 1.2 Check and Review Proposals . The 

SO reviews and checks all the incoming proposals. The 

proposals from new vendor's are put in a pending file until 
the qualification process is done. The non relevant 

proposals and the n on -qu a 1 i f i ed vendors proposals are 
discared. The relevant proposals from the qualified vendors 
are put in a pending file until closing date of RFP is over. 

Process 1 . 2 . 1 . 3 Record Proposals . The basic 

proposals data are recorded in the Proposals Monitor File 
(PMF). The data to be recorded are: 

* RFP Number 

* Proposals Serial Number (within the RFP number) 

* Vendor Name 

* Vendor ID 

* Proposals Received Date 

* Total Value Of Proposals 

Process 1.2.2 Issue Qualification Form . (QF) 

QF T s are issued to new vendors. Their proposals are put in a 
pending file until the investigation is completed. 

Process 1.2.3 Produce List of Received Proposals . 

After the closing date is over, a certain program in the 
computer is triggered to match the RFP Monitor File with the 
Proposals Monitor File and produce a report of all received 
proposals. The matching key is the RFP Number in both files. 
This list with the physical copies proposals are forwarded 
to A A . 
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The following is the suggested list produced by the 



computer : 



PROPOSALS LIST 



RFP PROPOSAL VENDOR DATE TOTAL 

NUMBER NUMBER NAME RECEIVED VALUE 



2 . RFC Function Description 

The potential for automation of this function is not 
too high because it is not the common case for the POW to do 
the contracting with vendors, except for small contracts. 
This function has high potential as a future DSS application 
for evaluating proposals and vendor selection, but the 
volume of RFC is not big enough in POW to be included in 
this thesis . 

The manual system of the RFC function will not be 
changed, except recording basic RFC data to produce status 
reports. Figure 4.7 shows how the RFC function. 

The data structure of the RFC is: 

* RFC Number (Register number) 

* Date Received 

* RFP Number 

* Requester (Force or Department) 

* RFC Sub j ect 

* Fund Letter Number 

* Fund Dollar Amount 
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* Vendor(s) Best and Final Offers 

* Technical Evaluation Ranking 

* Negotiation Base (Least Cost or Price Performance 
Ratio) 

j . Funding Contracts 

The funding contract function is also small because 
it is limited only to commercial contracts signed in POW. 
Like the RFC It is not big enough 'to be automated. For chat 
reason this function will not be changed, except the 
management of the guarantee letters of all contracts signed 
withUS vendors either in Egypt or in POW, currently about 
1500, This sub- function has great potential for automation 
because the Guarantee Letters ‘must be monitored by POW, This 
sub- function will be developed as a part of the Administer 
Contract function, 

4 . Administer Open Contracts 

By developing this function we could increase the 
efficiency of POW. The basic data about a particular 
contract must be recorded in the Contract Database File 
(CDF). The data structure of the contracts is: 

* Department Code (2 Characters) 

* Contract Number (Serial number within department 

code) 

* Contract Name (Heading of 50 characters ) 

* Contract Description (TEXT of 50 characters) 

* Contact Vendor Name 
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* 


Contract Vendor ID 


* 


Contract signed date 


* 


Contract Total Value 


* 


Contact Items (Repetitive group) 

* Unit of Issue UI 

* Quantities 


* 


Contract Summary 


* 


Inspection Schedule 


* 


Payment Schedule 


* 


Shipment Schedule 


* 


•Training schedule 


* 


Basic Attached document 


* 


Guarantee letters 


* 


Source of fund letter 


* 


Case designator (for the loan funded contracts) 


* 


Certif icates 


The 


following are the sub-f unctions to be automated: 
a . Payment 

b. Monitor shipment 

c , Monitor Personnel Training related to contracts 

d, Monitor Guarantee letters 

e , Reporting 

a. Payment 

The contracts are sorted into groups according 


to the 


specialized area. Each specialized officer is 
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responsible for one or more groups. The database for trie 
contracts must be centralized. The data about contracts can 



be retrieved and updated through the computer terminal. The 
following are details of the payment process: (Figure 4.8) 

Process 4.1.1 Register the Payment Documents . The 

payment documents are received and registered in the GLB 

then routed to the specialized officer. The payment 

documents consist of the original invoice, the shipment 

receipt from the Freight Forwarder (FF), and the certific- 
ates of manufacture and warranty. 

Process 4.1.2 Review and Check The Payment 

Documents . The specialized officer accesses the 
contract database and contract monitor file to check the 

documents against the previous payments, shipment schedule, 

etc. to be sure of meeting the requirements of contract. A 

pre-defined report may be produced to assist him in doing 

his job. The following is the suggested report format: 



SHIPMENT HISTORY 

CONTRACT SHIPMENT TOTAL DATE 

NUMBER NUMBER VALUE RECEIV ED 

The specialized officer can also retrieve detail- 
ed information about a particular contract or vendor to 
assist him in making his decision to approve the payment. 

The SO will be authorized to record the data 
about shipment notice and the certificates related to his 
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contract group area. The following is the data structure of 
the shipment notice: 

* Contract Number 

* Shipment Number 

* Shipment Date 

* Shipment Value 

* Shipment Items (Repetitive group) 

* Name 

* Unit o-f Issue 

* Quan t i ty 

* Vendor ID 

* Shipment data 

The SO approves the payment and forwards the 
payment documents to the Financial Officer (FO). 

Process 4,1,3 Check The Payment Documents By The FQ 
•The FO checks all the payment documents paying special 
attention to the validity of the invoice. He will be able to 
produce reports of all the payment information about a 
particular contract or vendor. He can also produce reports 
about the status of fund availability. The following is the 
suggested report format: 



PAYMENT HISTORY 

CONTRACT INVOICE DATE TOTAL 

NUMBER NUMBER. RECEIVED VALUE 
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The FO is the only officer authorized to record the 
Invoice information in the computer database. The data 
structure of the invoice is as follows: 



# 


Invoice Number 


* 


Contract Number 


# 


Vendor Code 



Date Recei ved 



* 


Due Date 


# 


Total Value 


* 


Invoice Items (Option) 

* Name 

* Unit of Issue 




* Quantity 



Process 4.1.4 Prepare The Payment Check . The FO 



prepares 


the payment checks after validation of all payment 


documents 


using the database to assist him in making his 


decision . 


The FO records the checks data in the database 



after getting the approval of payment from the POW director. 
The following is the data structure of the check: 



* 


Check Number 


* 


Date of Issue 


* 


Invoice Number 


* 


Bank 


* 


Value 



Vendor Company Name 
Check Contract Number 
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b 



Monitor Personnel Training 



Process 4,2 Monitor Personnel Training . The 

personnel training sub-function is very important. Two 
processes are related to the training: preparation and 

implementation of the training plan and following up of 
personnel during the training period in USA. 

Process 4.2.1 Pepare Training Plan . After signing 

the contract the training information is extracted from the 
contract and recorded in training database. The data 
structure for the training data are: 

* Contract Number 

* Line number related to training in the the 
contract 

* Number of personnel to be trained 

* Pre-request for training (repetitive group) 

* Training Period (repetitive group) 

* Location(s) (repetitive group) 

* Estimated Date of training (Repetitive 
group ) 

* Actual Date of Training 

Process 4.2.4 Personnel Affair in training The 

POW becomes responsible for all officers under training 
along the period of staying in the USA. The Administrative 
Officer in POW is responsible for preparing the monthly 
payment for all officers, mailing them the checks every 
month, travel reservations, internal transportation during 

check in/out in USA, and medical care. 
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4.3 Monitor Shipment 
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The following is the suggested data structure for 



personnel 


monitoring file: 


# 


Person Military Number 


* 


Rank 


* 


Name 


# 


Related Force/Department 


# 


Date Arrived 


* 


Date Leave 


* 


Training Location 

* Address 

* City 

* State 

* Zipcode 

* Phone Number 


* 


Point of Contact in the Training Center 


* 


Home Address during Staying in USA 

* Address 

* City 

* State 

* Zipcode 

* Phone number 


* 


Contract Number 


* 


Course Number 



Course Description 



# 

* Training Period 

* Start Date 

* End Date 

* Monthly payment rate 

The number of personnel may not exceed 200 officers 
on average any time during the year* The automation of this 
function is not included in this thesis because of the time 
constraint . 

c. Monitor Shipment 

Process 4*3 Monitor Shipment of Items to Egypt . 
The Freight forwarder (FF) is contracted to do this 
function* The POW shipment officer has an access terminal to 
the FF computer. No potential for automation is recognized 
for this function. The manual function will stay without 
change as presented in chapter II. 

d* Monitor Guarantee Letters 

Process 4*4 Monitor Guarantee Letters . The total 
number of active guarantee letters may exceed 1000 with a 
total value over $10 million. Keeping track of these letters 
is very important. The proposed system is a warning system 
to prevent losing the guarantee letters after they exceed 
their validity periods. The software requirement for this 
function is simple. All the Guarantee letters are recorded 
in a database file. A printed list is produce every week of 
the guarantee letters that need to be renewed. This list 
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is produced far enough ahead to allow enough time for 
requesting the renewal. The data structure for the guarantee 
letters is ; 

* Contract Number 

* Guarantee Letter number (within the Contract 
number ) 

* Bank issued from 

* V endor ID 

* Vendor Name 

* Total Value 

* The purpose of the guarantee letter 

* Starting Date of Validity 

* Ending Date of Validity 
e . Reporting 

Process 4.5 Prepare Reports . The reporting 
facility of the PC/FOCUS database is very powerful and can 
be used to generate any reports needed by POW. In chapter II 
we presented only the general kinds of reports that may be 
produced. In this Chapter, we inroduce specific reports to 
be generated. It is not necessary that all reports be 
printed; most of them may be needed only as a screen 
displays. PC/FOCUS has the facility to view the report on 
the screen first. If the user needs to print it, he can then 
issue two commands: OFFLINE to let PC/FOCUS forward the 
output to the printer and RETYPE to repeat the document. 



The following are a list of the proposed reports: 



( 1 ) The status Reports : 

Vendor Status Report 
RFP/Proposals Report 
De p a r t me n t / RF P Report 

- Department/Contract 

Vendor / Contract Report 
Department / Vendor 
Vendor / Department 

( 2 ) Progress Reports : 

Contract implementation over a period of time by 
the value received. 

Shipment of items over a period of time 
RFP Received and processed during a period 

( 3 ) Comparison reports : 

These kind of reports are very important for 
decision support. Mainly it can be used during 
evaluation functions. The financial modeling 
function of PC/FOCUS can be used to produce 
these kind of reports. The graphic terminal 
system may be used for the graphic presentation 
of these reports . 

5 . Generate Effective Vendor Database 

We need to build an effective vendor database for 
the potencial and qualified vendors who are most suitable to 
be supplier for the Egptian Armed Forces. This function has 






a highly payoff compared with the other functions because 
it’s relatively simple to implement on the computer and a 
great effort is needed in the manual system to prepare the 
vendor list for a particular RFP. It may take more than a 
week to prepare a vendor list for a particular RFP. 

In the USA there are over 135,000 manufacturers. We 
cannot practically put all the qualified vendors in USA in 
our database, otherwise it becomes very big. The practical 
approach to building an effective vendor Ddtabase for POW is 
to include initially only vendors who already have contracts 
with POW. We can then add the RFP- driven vendors to it i.e. 
all vendors who offer accepted proposals. Periodically, the 
vendor database is reviewed and non-active vendors are 
dropped. Other sources of potential vendors may be used such 
as: USA Armed Forces and Government suppliers, and Thomas 

Register . 

The following is the data structure for a specific 

vendor: 

* Vendor ID (A local code is used with a cross- 

reference table for vendor code) 

* Vendor Name 

* Vendor Point of Contact 

* Vendor Address 

* Street 

* City 

* state 
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* Zip code 

* Phone Number 

* Telex 

* Business Asset Rate 

* Business Start Date 

* Business Activities (Repetitive group) 

* Vendor Item Classes (Repetitive group) 

* Vendor Department Area 

* Vendor Supplier to USA Armed Forces 

* Vendor Previous Relation with POW 

* Vendor Rating Grade 

C. CONCLUSION OF THE CHAPTER 

This chapter was very important because all the 

necessary information to build the new system are now 

available. Each function is analyzed to determine whether or 
not be automated, The data elements for each function is 
determined also, the revisited DFD ! s are used to explain the 
system. The data dictionary section is moved to the next 
chapter to integrate it with the design issues for the new 
system. Figure 4.11 shows the logical relations between the 
Entities of the system, the lines with arrows represent a 

one to many relationship between the entities. In the 

designed system an entity may be divided into one or more 
database f ile . 
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V. SOFTWARE DESIGN OF POWCF SYSTEM 



A. OBJECTIVES 

DSS consists of three major components, a data base, a 
model base, and a dialog components. The objective of the 
software design is to build the data base components, the 
most important components in DSS. 



The DBMS is one of the three major components of a DSS. 
(The other two components are the dialog component and 
the model component.) A DBMS is an important tool for 
building a DSS, and a poor data base management 
. component can cause the failure of a DSS. LRef. 1] 

The software we use is the PC/FOCUS which allows easy 

building of the other two components as well. The POWCP 

system attempts to aim at: 

1. Improving the performance of POW in the Commercial 
Procurement system by providing the right inform- 
ation at the right time to the right person. The 
result of the system must affect the RFP function by 
reducing the time for preparing the list of vendors 
who are qualified to receive a particular RFP and 
improving the capability of POW to administer the 
open contracts . 

2. Introducing automated assistance to improve decision 
making in POW . 

B. DATABASE STRUCTURE 

1. Database File Relation 

The following are the database file relations that 
show the primary key fields in each file "underlined" 
and the other fields which are used for linking the file in 
the database . 
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PQWDEP ( REQ-ID , 



) 



POWRFP(R FP-NQ ) , DEP-ID , ...) 

POWRF C ( RFC-NO , RFP-NQ , DE PART-NO 1 , . . . ) 

PQWVNDR( VENDQR-ID , DEPCUSTOMER , ...) 

POWCONTR ( CON TR-NO , CON TRACT-PEP .CONTRACT-VID, ...) 

PQWBANKC BANK-NO , ...) 

POWINVOI ( IN VOICE- NO , INV-CONT-NO,INV-VNDR-ID,INV-CHECK-NO, 

. . . ) 

POWORDR ( PAYQRDER-NO , PAY-O-INV-NO.PAY-ORD-BANK, ...) 

POWCHECK( CHECK-NO , CHECK-IN V-NO .CHECK-BANK , . . . ) 

POWICLASC VENDOR -ID 1 , VNDR-ITEM-C , ...) 

POWVDEP (VENDOR-ID2 , VNDR-DEP-NO, ...) 

POWSHIPN ( SHIP -NOTICE , SHIP-CONT-NO,SHIP-INV-NQ t . . . ) 

POWCITEMC CONTR-NO 1, ITEM- CODE, ...) 

POWBNK AC (BANK-NO, BANK-ACCOUNT, ...) 

2. Database Schema 

Figure 5.1 shows the relations between the database 
files. Notice that the first five files represent the 
commercial procurement cycle until signing of the contract. 
The rest of the files represent the administration contract 
function. The connection between the two groups is done via 
the contract file. This structure provides the most simple 
way of building the database. The key fields are underlined 
and the other fields are used to connect the different files 
which can be done easily by the join facility of PC/FOCUS. 
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From this structure we can generate many of the logical 
structure to produce the required reports. 

C. DESIGN IMPLEMENTATION ISSUES 
1 . Data Dictionary 
a. Normalization 

Since we are going to build the DSS generator of 
POWCP system, the database, normalization of data is very 
important as a necessary logical step before undertaking the 
physical design of the database. One of the objectives of 
normalization is to get the simplest possible representation 
of data that we can get. In other words, remove the complex 
relationships between data structures by removing repeating 
groups (first Normal Form (INF)), group all nonkey data 
elements in a structure to be fully functionally dependent 
on a single primary key in the same structure (Second Normal 
Form (2NF)), and remove all the nonkey data elements which 
are functionally dependent on other nonkey data element in 
the same structure (Third Normal Form ( 3 N F ) ) . The reasons to 
do data normalization before designing the physical 

database are: a. Construct the simplest possible data 

structure before loading the database because it is 
difficult to change the structure of the database after 
loading the actual data to the system (although PC/FOCUS 
allows data base rebuilding via the REBUILD COMMAND which 



allows 



reorganizing, reindexing, and rebuilding damaged 



FOCUS files); b. Normalization prevents deletion anomalies 

which means that we may lose facts about two entities by one 

deletion. For example if the item class only exists in the 

vendor record, if only one vendor supplies this item class 

and this vendor does not exist in our database, the item 

class also will not exist. Normalization also prevents 

insertion anomalies which constrains inserting an entity 

unless another logically unrelated entity is also inserted. 

Both for the manual and for computer systems, it usually 
is easier and cheaper to change the logic of a process 
than to change the structure of a data store. 

Consequently, the simpler and more general the structure 

of a data store, the easier and cheaper it will tend to 
be to make changes in the data. [Ref. 3] 

b. RFP Structure Normalization (An Example) 

The Request For Proposals (RFP) data structure 
will be used as an example to apply the normalization 
technique. For the other data structures, we present the 
final result in 3NF with the proper names that will be used 
in the physical design of the database. 



RFP Data Structure: 



(Not normalized) 



RFP Number 
Date Received 

Requester Code (Force or Department) 

+ - Requester Name (Two character code) 

RFP Subject 

* - Items Needed (Repetitive group) 

* - Item Name 

* - Uni t of Issue 

* - Quantity 

* - Items Class (key words such as: Tools, 

Engines , Pumps , Computers, 

e t c . ) 

Estimated Dollars 

Source of Funds (Budget, Loans, Others) 

* - Suggested Vendor Names (Repetitive group) 
The data marked with "* M are repeating groups. 

The data elements marked by are not functionally 

dependent on the RFP number. No data elements functionally 
dependent on other data elements appear in the RFP data 
structure. To do the normalization, first we separate the 



repeating groups as follows: 



" + " and 
structures 
in 2 NF : 



RFP Data Structure (INF) 

RFP Number (Key data element) 

Date Recei ved 
- Requester Code 
Requester Name 

RFP Subject RFP Number 

Items Needed 
Item Name 
Unit of Issue 
Quantity 



RFP Number 
Item Classes 

Estimated Dollars 
Fund Source 



RFP Number 
Sugg. Vendor Name 

Second, we separate the data elements marked by 
leave the Requester Code to link the two data 
as needed. The following is the data structure 



1 1 4 



RFP Data Structure 



( 2 NF ) 



RFP Number . (Key data element) 

Date Received 

Requester Code Requester Code 

Requester Name 

RFP Subject RFP Number 

Items Needed 
Item Name 
Unit of Issue 
Quantity 
RFP Number 
Item Classes 

Estimated Dollars 

Fund Source 



RFP Number 
Sugg. Vendor Name 

The above structure is in third normal form. We 
notice that the original RFP data structure is divided 
physically into six normalized data structures. These 
structures can be logically grouped together to form the 
original data structure or any other structure as required. 
In the following page the new six data structure are 



presented 



POWRFP FILE 



*RFP_NO 
RF P_DATE 
+REQ_ID 
RF P_S U B J E CT 
RFP_COMMENT 

POWREQ FILE : 

*REQ-CODE 

REQ-NAME 

RFPITEM FILE : 

+ RF P_NO 1 
+ITEM_CODE 
UNIT_OF_ISSU 
QUANTITY 

RF P I C L AS FILE: ITEMCLAS 



+RFP NO 



•ITEM CLASS 



FILE 



+ITEM CLASS 



SPECFI CAT ION 



The new structure of the RFP data structure is divided 



into six files which are in the 3 N F a n-d prevent deletion or 
insertion anomalies as we can see from the RFPICLAS ana 
ITEMCLAS files. We notice that the key fields are identified 
by " * " which means only one occurrence is allowable for each 
value of a key. These fields must be indexed to allow joins 
between other records of the same values in PC/FOCUS. The 
fields identified by means that these fields can be used 
for joins between records. Combining two fields of type "+" 
form a key of type which uniquely identifies one 
occurrence of a record. 

c . File Structure 

The following are the database record descrip- 
tions which are produced using the PC/FOCUS Filetalk 
utility. The Filetalk utility allows the user to 
interactively create Master File Descriptions (MFD). All 
MFD's are described as a single record (segment). Each 
record contains a group of relevant data. Notice that every 
name of a record is preceded by the procurement office 
initials, POW, to allow easy recognition of the files and 
prevent it from accidental deletion. Note that the key field 
of each record is marked by at the beginning of the 
line. The other key fields which may used for joining the 



files are underlined 



FILENAME:POW PEP, SUFFIX: FOC 



(Force or Department File) 



SEGNAME=0NE,SEGTYPE:S1 

»FIELDNAME: DEPART ID , ALIAS:DEP, FO R M AT = A2 , F I EL DT YP E = I , 3 
FIELDNAME : DE P AR T_N AM E , ALIAS = DEPN , FORMAT = A25 , S 

FILENAME=POWRFP , SUFFIX=FOC (Request For Proposals) 

SEGNAME:ONE,SEGTYPE:S1 

*FIELDNAME: RFP NO , ALIAS=RFPN , FO RM AT : I 6 , F I E LDT Y P E : I , $ 

FIELDNAME=RFP_DATE , ALIAS=RFPD, FOR M AT = I 6MD Y , $ 

FIELDNAME= DEP ID , ALIAS = DEPC, FORMAT = A2 , 5 

FIELDNAME = RF P_SU B J ECT , ALIAS:SUBJ, FORMAT: A50 , $ 

FIELDNAME: N_OF_V E N DO R S , ALIAS:NOV, FORMAT:I2 , 3 

FIELDNAME: NOF_PROPOSAL , ALIAS=NOP, FORMAT=I2, . $ 

FIELDNAME:RFP_ COMMENTS, ALIAS:, FORMAT = A50 , $ 

FILENAME:PQWRFC , SUFFIX:FOC (Request For Contracting) 

SEGNAME=ONE,SEGTYPE=S1 

*FIELDNAME: RFC NO , ALIAS:RFCN , FO R M AT = I 6 , F I E LDT Y P E : I , $ 

FIELDNAME=RFC_DATE , AL I AS = R FC D , FORMAT: I 6MDY , $ 

FIELDNAME = R_FP_NOJ_ , ALIAS = RFPN 1 , F0RMAT:I6, $ 

FIELDNAME: DEPART N0 1 , ALIAS:DEPN1, FORMAT: A2 , $ 

FIELDNAME:RF C_SU B J ECT, ALIAS:RFCS, FORMAT:A50 , $ 

FIELDNAME=FUND_LETTER , ALI AS:FLN , FORMAT:AjO, $ 

FIELDNAME:FUN D_AMMOU NT , AL I AS : F AM OU NT , FO R M AT: D 1 2 . 2M , $ 

FIELDNAME:RFC_COMMENT , AL I AS : RF C COM , FO R M AT : A5 0 , $ 



FILENAMES OWVNDR,SUFFIX:FOC 



(Vendor File) 



SEGNAME=0NE,SEGTYPE=S1 



*FIELDNAME= VENDOR 


ID, 


ALIAS: VCODE 


, FORMAT:I4 , FIELDTYPE: 


T 

x » 


FIELDNAME=THOMAS_ 


VOL_N , 


ALIAS:THVN , 


FORMAT=I2 , 


3 


FIELDNAME=THOMAS_ 


P AG_N , 


ALIAS:THPN , 


FORMAT:! 3 , 


3 


FIELDNAME=VENDOR_ 


NAME , 


ALIAS: VNAME , 


FORMAT:A50 , 


3 


F I ELD NAM E = POF_CON TACT , 


ALIAS: POFC , 


FORMAT:A25 , 


3 


FIELDNAME=VENDOR_ 


ADRES , 


ALIAS:VADRS , 


FORMAT :A25 , 


3 


FIELDNAME:VENDOR_ 


CITY , 


ALIAS: VCTY , 


FORMAT:A 1 5 , 


3 


FIELDNAME:VENDOR_ 


STATE , 


AL I AS : V ST A , 


FORMAT:A4 , 


3 


FIELDNAME: VENDOR_ 


ZIPC , 


ALIAS:VZIPC , 


FORMAT:I 7 , 


3 


FIELDNAME=VENDOR_ 


PHONE , 


ALIAS = VPH , 


FORMAT:A 1 4 , 


3 


FIELDNAME=VENDOR_ 


TELEX , 


ALIAS=VTLX, 


FORMAT: A 1 2 , 


3 


FIELDNAME=VENDOR_ 


ASSET , 


ALI AS:VASS , 


FORMAT: A6 , 


3 


FIELD NAME = VEN DO R_ 


START , 


AL I AS = V STD , 


FORMAT:A4 , 


$ 


FIELDNAME: V_ ACTIVITIES , 


ALI AS:VAC , 


FORMAT:A50 , 


3 


FIELDNAME:DEP CUSTOMER, 


ALI AS:DEPC , 


FORMAT:A2 , 


3 



FILENAME:POWCONTR > SUFFIX = FOC (Contract File) 

SEGNAMErONE , SEGTYPErS 1 

*FIELDNAME = CONTRACT NO, ALIAS = CN, FO R M AT = I 6 , F I ELDT Y P E = I , $ 



FIELDNAME=CONTRACT_NAM, ALT AS=CN AM , FORMAT=A50 , $ 
FIELDNAME:CONTRACT_DES , ALIAS = CDES, FORMAT = A50 , $ 
FIELDNAME = CONTR ACT PEP , ALIAS = CDEP, FORMAT = A2 , $ 
FIELDNAME= CONTRACT VIP , ALIAS=CVID, FORMAT:I4, $ 
FIELDNAME=CONTRACT DAT, ALIAS=CDATE, FO R M AT : I 6M DY , $ 



FIELDNAME = C 0 NT_V AL UE , A LI AS = C V A L U E , FO RM AT = D 1 4 . 2 , 3 

FIELDNAME=CON T_COMM , ALIAS = CCOMM, FORMAT: A50 , 3 

FILENAME=PQWBANK , SUFF IX : FOC (Bank File) 

SEGNAME:ONE,SEGTYPE=S1 

*FIELDNAME = BANK NO , ALIAS = BNO, FO RM AT = I 2 , F I EL DT Y P E = I , $ 

FIELDNAME=BANK_NAME , ALIAS = BNAME, FORMAT = A20 , $ 

FIELDNAME = BANK_ADDRES , AL I AS = B A DR E S , FOR M A T = A2 5 , 3 

FIELDNAME = BANK_CITY , ALIAS = BCTY , FORMAT = A25 , 3 

FIELDNAME = BANK_STATE , AL I AS : BST ATE , FO R M AT : A 4 , 3 

FIELDNAME = BAN K_Z I P C , ALIAS=BZIPC, FORMAT = 17 , $ 

FIELDNAME:BANK_PHONE , AL I AS = B PHO N E , FO RM AT = A 1 4 , $ 

FIELDNAME: B AN K_TE LEX , ALI AS: BTLX , FORM AT: A 1 4 , $ 

FILENAME=POWINVQI ,SUFFIX=FOC (Invoice File) 

SEGNAME=ONE , SEGTYPE=S 1 

*FIELDNAME = INVOICE NO , ALIAS=INVN, FO RM AT : I 6 , F I E LDT Y P E = I , 3 

FIELDNAME= INV CONT NO , ALIAS=INVCN, FORMAT=I6, 3 

FIELDNAME=INVOICE_SUBJ , AL I AS = I N VSU B J , FO RM AT = A 5 0 , 3 

FIELDNAME = IN V_V EN DR_I D , AL I A S = I N V V I D , FO RM AT = I 4 , $ 

FIELDNAME=INVOIC E_D ATE , ALIAS=INVD, FORMAT: I 6MDY , $ 

FIELDNAME = INVOIC E_V ALU , ALIAS=IVLU, FO RM AT: D 1 2 . 2M , $ 

FIELDNAME: INV_DUE_DATE , ALIAS=IDUE, FORMAT: I 6MDY , $ 

FIELDNAME: INV CHECK NO , ALI AS = I C H K NO , F 0 RM AT= 1 8 , 3 

FIELDNAME:IN V_P A Y_D ATE , ALIAS = IPD, FORMAT: I 6MDY , 3 

FIELDNAME:IN V_ COMM, ALIAS:, F0RMAT:A50 , 3 



FILENAME=POWORDER ,SUFFIX=FQC 



(Pay Order File) 



SEGNAME = ONE , SEGTYPE = S 1 
*FIELDNAME= PAY ORDER NO , ALIAS 
FIELDNAME = P A Y_OR D R_DAT , ALIAS 
F IELDNAME: PAY 0 INV NO , ALIAS 
FIELDNAME= PAY ORD BANK , ALIAS 
FIELDNAME = PA Y_0_V ALU E , ALIAS 
FIELDNAME: PAY 0 VIP , ALIAS 

fieldname = pay_tov;hom, alias 

FILENAME=POWICLAS ,SUFFIX:FOC 
SEGNAME = ONE , SEGTYPE = S 1 
*FIELDNAME = VENDOR ID 1 , ALIAS 
FIELDNAME = VND R_IT EM_C , ALIAS 

FILENAME=POWVDEP ,SUFFIX=FOC 
SEGNAME=ONE ,SEGTYPE=S1 
♦FIELDNAME: VENDOR ID2 , ALIAS 
FIELDNAMEa VNDR PEP NO , ALIAS 

FILENAME=POWSHIPN , SUFFIX=FOC 
SEGNAME = ONE , SEGTYPE = S 1 
*FIELDNAME= SHIP NOTICE , ALIAS 
FIELD NAME=SHIP CQNT NO, ALIAS 



PON, FORMAT=I8 ,FIELDTYPE=I , $ 



POD, FORMAT = I 6MD Y , =, 
POINVN,FORMAT=l6, $ 
POB, FORMAT= 1 2 , $ 
POV, FORMAT: D 1 2 . 2M , $ 
POVID, FORMAT:I4, $ 
POTO, FORMAT: A25 , $ 



( Items Class File) 

VID1, FORMAT:I 4 , $ 

VIC, FORMAT=A15, $ 

(Vendor Department File) 

VCODE2 , FORMAT:I 4 , $ 

, FORMAT:A2, $ 

(Snipment Notice File) 

SHN, FORMAT:I6 , FIELDTYPE=I , $ 

SHCN, FORMAT:I4, $ 



FIELDNAME= SH I P_SU B J E CT , ALIAS=SHS, FORMAT = A50, $ 

FIELDNAME= SHIP INV NO , ALIAS=SHIN, FORMAT=I6 , $ 

FIELDNAME = SHI P_D A T E , ALI AS=SHD , FORMAT= I 6MDY , $ 

FILENAME=POWCITEM ,SUFFIX=FOC Contract Item File 

SEGNAME=0NE,SEGTYPE=S1 

*FIELDNAME= CONTRACT NO 1 , ALI AS = C N 1 , F0RMAT = I 6 , $ 

FIELDNAME= ITEMD CODE , ALIAS=ICOD F0RMAT=A12 $ 

FIELDNAME=ITEM_DESCRP ALIAS=IDESC F0RMAT=A30 $ 

FIELDNAME=UNIT-OF-ISSUE ALIAS-UI FORMAT=A2 $ 

FIELDNAME=CONT_QTY ALIAS=CI, • F0RMAT=A30 , 3 

FILENAME= POWBNKAC , SUFFIX =FOC 
SEGNAME=ONE , SEGTYPE=S1 

*FIELDNAME = BANK NUNBER , ALIAS = BID1, FO RM AT = 1 2 , F I E L DT YP E = I , $ 

FIELDNAME= BANK ACCOUNT , ALIAS=BACC, FORMAT=A10, $ 

2 . Using PC/FOCUS for the POW Softeware 

The purpose of this section is to justify the use of 
PC/FOCUS as a DSS generator for the POW system. Some of the 
most important and useful features of PC/FOCUS are 
highlighted below. 

a. Files Description 

PC/FOCUS supports a hierarchical model, i.e. the 
file description allows a one to many relationship between 
segments (records) in FOCUS file or the parent to many child 
segments. The data description language of PC/FOCUS allows 



free format delimited by $ to signify the end of single 



description. A checking procedure can be used to check 
errors in the file description. After data entry, changes in 
the file description are not allowed unless they are a part 
of reorganization of the physical database. (Rebuild 
facility of PC/FOCUS allows down loading an " old 11 physical 
data base to a " new 11 description carefully made by the 
designer. File relationships ( cr o s s -r e f e r e n c e of files ) in 
the database can be made static through FOCUS file 
description as a parent child relation or dynamic using 
PC/FOCUS JOIN command which can be invoked when needed to 
link two entire file structures. The condition for using the 
JOIN command is to allow at least one field in the desired 
segment of each file to be of type "indexed" in the file 
description. Any number of fields may be indexed on a 
segment. PC/FOCUS FileTalk also allows easy checking of file 
descriptions by producing a graphical representation of 
files and segment relations. 

b. Data Manipulation in PC/FOCUS 

A non-procedural language is- used for data 
manipulation and producing reports from the database. Two 
functional types of manipulation language are available in 
PC/FOCUS: the transaction processor and the dialogue 

mana ger . 

( 1 ) The Transaction Processor . is used for 

report preparation by invoking the MODIFY command and typing 
an imperative English statement consisting of one or more 
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verbs followed by verb objects and optionally by various 
other phrases. All these statement follow 'the general rules 
of English grammar. The request statement contains all 
information the user has to provide in order to retrieve the 
desired records, perform any calculations, sort lines, 
accumulate totals, etc. Information which is not provided 
explicitly by user will be supplied by FOCUS as default 
options. The transaction processor has a facility to create 
screens for f i 1 1 - i n - 1 he- b 1 a n k data entry called FIXFORM. The 
MATCH subcommand is used to designate fields to match. 
Logical subcommands are used to process any demands from the 
database. It is possible to store FOCUS transaction 
processing routines in a command file for later use. 

(2) The Dialogue Manager . is a stored 
procedure that may contain variable information for which a 
value is provided only at the time of execution. The 
variables can be used to represent numeric constants, dates, 
or to conduct a dialogue by prompting the user for a 
response. The Dialogue Manager is invoked by typing the 
FOCUS command "EXEC" or "EX" followed by the name of the 
procedure. 

c. Built-in Facilities in PC/FOCUS 

In addition to file description and data 
manipulation, there are many important facilities that make 
using PC/FOCUS database atractive for our system. The 
following are the summary of each facility as presented in 
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[Ref. 8 j 



(1) Describing External Files . The report 
request language can be used on data files that are not 
maintained by FOCUS and, hence, are external. These are 
existing files which are maintained by, or extracted from, 
other systems . 

(2) Maintaining FOCUS database . A simple 
language is used to control all the processes of adding new 
records to FOCUS database, deleting records,and changing 
values in existing records. Coupled with a transaction 
validation, computational, and logging facilities, the 
result is surprisingly brief set of ideas that must be 
learned in order to maintain FOCUS database. 

( 3 ) SCAN - Interactive Editing Facility . The 
SCAN facility is designed to take advantage of an inter- 
active environment. It allows a user to ’browse 1 through a 
FOCUS file of any size by issuing one-line commands such as 
TYPE, NEXT, REPLACE, ETC. and receive an immediate response 
before issuing the next command. Users familiar with a text 
editor will find the similarities useful in learning SCAN. 

( 4 ) ANALYSIS - Formal Statistical Analysis , 
normal statistical techniques such as multiple regression, 
step-wise regression, and correlation analysis are performed 
on data in FOCUS (or external) files. Control over the 
techniques is exercised in an interactive dialogue. The 
displays include all of the formal statistical quantities. 
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(5) GRAPHS . The report request language is 



used to phrase and control graphical displays such as point 
plots, bar charts, histograms and scatter diagrams. Normal 
terminal output or high resolution graphics can be prepared. 
Default values are used for widths, grid values, etc. to 
simplify the process, but user can specify precise values 
when customized plots are needed. 

(6) User Defined Language . Users can change 
the language and vocabulary of FOCUS to suit their own needs 
and pr ef erences . 

(7) Financial Modeling Language . The report 
request language has a series of features designed 
specifically for the preparation of 'row oriented* reports. 
These arise frequently in financial applications where 
reports such as Balance Sheets and Cash Flow statements are 
needed . 

( 8 ) FIDEL-FOCUS Interactive Data Entry Language 
FIDEL enables the design and implementation of full screen 
interactive data entry systems as part of the data 
maintenance facility. It also provides easy development of 
'menu' selection processes. 

3 . Database Creation 
a. Data Entry 

The Automode utility is used to enter data in 
the database. Test data have been generated to load the 
database. Real data will be loaded during the implementation 
phase . 
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Validation 



b. 

PC/FOCUS allows validation of data during data 
entry. A record is rejected if any violation of field format 
occurs or if a record with the same key field is entered 
twice. In the latter case the last one entered will be 
rejected by PC/FOCUS. Automode does not allow range 
validation. There is a very powerful tool for interactive 
data entry, FOCUS INTERACTIVE DATA ENTRY LANGUAGE (FIDEL)) 
FIDEL allows the user to enter data through a visual 'fill 
in the form* method. After each successful transaction, the 
data portions of the screen are blanked out, leaving only 
the mask. If an error is discovered in the transaction an 
error message will appear on the bottom of the screen. A 
bell will ring (if the CRT is so equipped) and the screen 
will not blanked out, thus giving the operator a chance to 
correct the error and retransmit the screen. The FIDEL 
provides validation and protection mechanisms during 
interactive data entry. The complete language rules and 
facilities are presented in the PC/FOCUS user manual [Ref. 
3J. In this thesis we are not going to use this tool 

because of the time limitation for the thesis. Auto mode 
provides adequate facility for data entry in this prototype. 

c . Security 

One problem with using the computer is the 
possibility of losing data. An important step in developing 
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any computer system is instituting procedures for backup of 
the actual data in the database and for prevention of 
unauthorized access to data. In our system, the security 
procedure is simple. FOCUS files containing data have an 
extension xxx.FOC to distinguish them from other files. The 
prefix, PQW is used to precede all files generated by the 
system. Only an authorized person is allowed to delete these 
files. Every week a backup for all files in the database is 
done on floppy diskettes. Data entry and updating is 
limited to authorized persons only. PC/FOCUS has powerful 
tools for security which can be used for later development 
of. the system. 

d . Database Si ze 

The following table shows the length of the 
different database files: 



FILE NAME 


LENGTH 


ORGANIZATION 


NO OF RECORDS 


POWDEP 


27 


Indexed 


20 


POWVNDR 


223 


Indexed 


500 


POWICLAS 


34 




200 


POWVDEP 


6 




1 000 


POWRFP 


1 1 8 


Indexed 


800 


POWRFC 


1 62 


Indexed 


1 50 


POWCONTR 


182 


Indexed 


600 


POWC ITEM 


36 




3000 


POWINV 


154 


Indexed 


2000 


POWORDR 


63 


Indexed 


700 


POWCHECK 


63 


Inde xed 


1300 


POWBANK 


1 1 1 


Indexed 


20 


POWBNKAC 


1 2 




40 


POWSHIPN 


72 


Indexed 


2000 


TOTAL 


1263 




1 2530 
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4 . Using the Database 



The database can be used for all the POWCP by using 
the Tabletalk utility, 

a. RFP process 

(1) Routine # 1 , The routine is generated to match 
the data classes of any particular RFP with the data classes 
of all vendors. The result is a vendor list for all vendors 
that matches the data classes of the RFP. 

(2) Routine # 2 . This routine generates an 
RF P / P r o po s a 1 s list which summarize the RFP process and shows 
all proposals received from all vendors. This list is send 
along with the physical proposals to AA. 

(3) Routine // 3 . This is a general purpose routine 
which produces a list of the basic data in each database 
file. This routine can be enhanced to produce a variety of 
lists which suit certain logical conditions such as a list 
of all vendors with specific data classes. Of course we have 
to join the vendor data class file with the vendor file 
before we can generate the reports. 

b. Administer Open Contacts Function 

(4) Routine ff 4 . Produce a list of all invoices 
paid to a particular contract with its values and paid 
dates. The join between the contract file and the invoices 
file must be done before we use the Tabletalk. The same 
routine is generated by the Tabletalk. Similar routines can 
be generated for the pay order and the shipment notice. 
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(5) Routine // 5. Produce a list of all checks paid 



to a particular vendor. Joins with the vendor file and the 
checks file are necessary before producing the report. 

(6) Routine fl 6 . Produce a Payment Plan for all 
invoices received and validated to be paid on a schedule 
according to the due dates of each invoice. This list allows 
the financial officer to manage the payment in the most 
effective way and prevent missing payment of any invoice. 

(7) Routine ff 7 « Produce the financial status 
about all active contracts which shows the contracts against 
the amount of money paid for each one. This report is very 
important for the cash flow management of the fund dedicated 
for the contracts. 

(8) Routine # 8 . A validation list of all check 
values and dates issued to a particular bank. This list can 
be used .to check the balance sheet of the bank. This routine 
can be adapted to produce reports to monitor payment from 
loans . 

(9) Routine # 9 » Produce a status list of each 
contract from the point of view of the shipment and compare 
these reports with the contract terms. The importance of 
this report comes from its ability to measure vendor 
performance and address any delay from the schedule to 
allow the contracting officer to take the necessary action 
in suitable time. 



(10) 


Routine 


it 


1 0 . 


Produce 


a list 


of the 


received 


shipment 


notices 


to 


compare it 


with the 


reports 


received 


from the 


Freight Forwarder 


to check the performance 


of FF. 


cm 


Routine 


it 


1 1 . 


Produce 


list of 


of f i cer s under 


training 


for each 




contracts with information about the 


training 


period. 














(12) 


Routine 


it 


12. 


Produce 


mailing list each 


month to 


send the 


monthly 


salary 


. This 


list takes 


much time in the 


manual system. 












* 


(13) 


Routine 


it 


13. 


Produce 


a list of 


training 


schedule 


dates to 


inform 


AA 


ahead of 


time to 


pr epar e 


and send 


training 


officers. 














(14) 


Routine 


it 


14. 


A list 


is produced of 


all the 



Guarantee letters whose validity date is close to the end of 
the validity period, sorted by date so the renewal can be 
done in a suitable amount of time. This list is produced as 
required to assist the Financial officer in following the 
guarantee letters, 

5 . Designed Software 

The POW software is designed as a menu driven by the 
user. The POW main menu screen is appear when issue the name 
of the main module (EX POWMAINM . FEX ) . Selecting the options 
from the screen, each menu leads the user to another one. A 
help facility is provided to let users move from one screen 
to another. Three utilities we are going to use are the 

Filetalk which allow describing the Master Data File (MDF), 
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the Automode which allow loading the database, and the 
Tabletalk which allow producing different reports. Describ- 
ing MDF is already done by the author after determining the 
software requirements of POWCP, a meaningful names is select- 
ed to allow easy understanding for the user. The following 
pages illustrate a navigation through the designed system: 



Screen # 1 ,Main Menu 



WELCOME TO 

POW DECISION SUPPORT SYSTEM 
MAIN MENU 

DATA ENTRY / UPDATE / DELETE .... 1 



CREATE NEW FILE DESCRIPTION 2 

GENERATE REPORTS 3 

EXIT 4 

HELP 5 

SELECT (12345) 



Select Option 1 



WELCOME TO THE PC/FOCUS 
AUTOMATIC DATA MANAGEMENT SYSTEM 



PLEASE ENTER THE NAME OF THE FILE 
YOU DESIRE TO MODIFY: 

File name --> POWDEP 



Screen // 2, Main Edit 



AUTOMATIC DATA MANAGEMENT FILE POWDEP 
PLEASE SELECT A PROCESS 

1 ADD NEW RECORDS 

2 ADD NEW RECORDS, UPDATE EXISTING RECORDS 

3 UPDATE EXISTING RECORDS ONLY 

4 DELETE RECORDS 

5 RETURN TO MAIN MENU 



ENTER YOUR SELECTION (1234) 



Select Option 1 



AUTOMOD OPTION //1...ADD NEW RECORDS 



'TAB' FOR NEXT FIELD 'ENTER' TO TRANSMIT DATA 

' F7 ' FOR PRIOR SCREEN ' F8 ' FOR NEXT SCREEN 

' F3 ' TO RETURN TO PREVIOUS MENU 



DEPART ID : 
DEPART NAME: 
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Enter Data 



DEPART ID : 02 

DEPART NAME: ARMAMENT AUTHORITY 

Response — >... RECORD ACCEPTED ENTER NEXT RECORD .... 



Enter the same data to check validation facility 



DEPART ID : 02 

DEPART NAME: ARMAMENT AUTHORITY 



Response — >... RECORD ALREADY EXISTS REJECTED 



Select option 2 in Edit Screen 



AUTOMOD OPTION #2 ... ADD/ UPDATE RECORDS 



'TAB' FOR NEXT FIELD 'ENTER' TO TRANSMIT DATA 

' F7 ' FOR PRIOR SCREEN ' F3 ' FOR NEXT SCREEN 

'Fj' TO RETURN TO PREVIOUS MENU 



DEPART ID : 



DEPART NAME: 



DEPRESS ENTER 



Enter key ( 02 ) 



DEPART ID : 02 

DEPRESS ENTER 

DEPART NAME: ARMAMENT AUTHORITY 

FOCUS response — > UPDATING EXISTING RECORD 



Enter new Department (03) 



DEPART ID : Oj 



DEPART NAME: TANK 



DEPRESS ENTER 



Acknowledge — > ADDING NEW RECORD 



1 



Select option 3 in Edit Screen 



AUTOMOD OPTION // 3 • • .UPDATE EXISTING RECORDS 



'TAB' FOR NEXT FIELD 'ENTER' TO TRANSMIT DATA 

' F7 ' FOR PRIOR SCREEN ' F3 ' FOR NEXT SCREEN 

' F 3 ' TO RETURN TO PREVIOUS MENU 



DEPART ID : 03 



DEPART NAME: TANK 



DEPRESS ENTER 



ENTER NEW VALUES 



Enter new record 



DEPART ID : 04 



DEPART NAME: 



DEPRESS ENTER 



Acknowledge — > RECORD DOES NOT EXIST .... ENTER NEXT RECORD 



Select 


Option 3 in Edit 


Screen 








AUTOMOD OPTION 


#4. ..DELETE EXISTING RECORDS 


' TAB ' 
' F7 ' 


FOR 

FOR 


NEXT FIELD 
PRIOR SCREEN 

' F 3 ' TO RETURN 


'ENTER' TO TRANSMIT DATA 
' F 8 ' FOR NEXT SCREEN 

TO PREVIOUS MENU 


DEPART 


ID 


: 02 




Ack no w 1 ed 2 & 




. RECORD DELETED 











'The following are the basic screen of POWCP system. 
Notice that we select the add/update option and dropped the 
help part of each screen to save space. 



Screen U 3» Vendor Data 



VENDOR ID : 



THOMAS-VOL-N : 
VENDOR NAME: 
POF CONTACT: 
VENDOR ADRES: 
VENDOR CITY: 
VENDOR ZIPC: 
VENDOR TELEX: 
VENDOR START: 



DEPRESS ENTER 

THOMAS PAG N: 



VENDOR STATE: 
VENDOR PHONE: 
VENDOR ASSET: 



Screen // 4, Item class 



VENDOR I D 1 : 

VNDR ITEM C: 

DEPRESS ENTER 



Screen 5, Vendor / Department 



VENDOR ID2 : 
VNDR DEP NO: 



Screen if 6,RFP Data 



RFP NO 



RFP DATE : 
RFP SUBJECT: 
N' OF VENDORS: 
RFP COMMENTS: 



DEPRESS ENTER 

DEP ID : 

NOF PROPOSAL: 



Screen # 7, RFC Data 



RFC NO 



RFCDATE : 
DEPART NO 1 : 

RFC SUBJECT: 
FUND LETTER: 
FUND AMMOUNT: 
RFC COMMENT: 



DEPRESS ENTER 

RFP NO 1 
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Screen it 6, Contract Data 



CONTRACT NO: 



CONTRACT NAM 
CONTRACT DES 
CONTRACT DEP 
CONTRACT DAT 
CONT COMM : 



DEPRESS ENTER 



CONTRACT VID: 
CONT VALUE : 



Screen # 9>Contract Item 



CONTRACT NO 1 : 
CONT ITEM : 



Screen it 10, Invoice 



INVOICE NO : 



INV CONT NO: 
INVOICE SUBJ 
INV VENDR ID 
INVOICE VALU 
INV CHECK NO 
INV COMM : 



DEPRESS ENTER 



INVOICE DATE 
INV DUE DATE 
INV PAY DATE 



Screen It 11, Pay order 



PAY ORDER NO: 

DEPRESS ENTER 

PAY ORDR DAT: PAY 0 INV NO: 

PAY ORD BANK: PAY 0 VALUE: 

PAY 0 VID : 

PAY TO WHOM : 



Screen 12, Pay Check 



CHECK NO 



CHK PAY DATE: 
CHK BANK : 
CHK VENDR ID: 
CHK TO WHOME: 



DEPRESS ENTER 



CHK INV NO : 
CHK VALUE 



Screen It 1 3 » 3ank Data 



BANK NO 



BANK NAME 
BANK ADDRES 
BANK CITY 
BANK STATE 
BANK PHONE 



DEPRESS ENTER 



BANK ZIPC : 
BANK TELEX : 



Screen it 14, Bank Account 



BANK N0 1 : 

BANK ACC NO: 

DEPRESS ENTER 



Screen # 15, Shipment Notice 



SHIP NOTICE: 



SHIP CONT NO.- 
SHIP SUBJECT: 
SHI.P INV NO: 



DEPRESS ENTER 



SHIP DATE : 



VI. CONCLUSIONS AND RECOMMENDATIONS 



A. CONCLUSIONS: 

1. The POW system as presented in this thesis is not 
exactly the same as the existing POW system because of time 
and travel constraints, however, the main functions, 
problems and opportunities of POW have been addressed. 
Adaptation of the system to POW or any other Procurement 
Office will need only minor effort compared to the effort 
spent in developing this system. Fortunately PC/FOCUS with 
its Fourth Generation Language and facilities will allow 
easy adaptation of the system. 

2. No system, no matter how efficient it is, will be 
effective if it is not employed by its users. There is the 
possibility that the proposed system will not be used any 
more effectively than the present manual system. However, it 
is felt that the probability of this happening will decrease 
as the users realize the benefits of the system. During the 
analysis phase all users of the system showed willingness to 
participate in using a computer system which would improve 
the effectiveness of the system. The manual system has no 
more capability to deal with the increased demand for 
procurement activities in the USA market. Of course, it is 
the responsibility of POW to support and require use of the 
system once it has been proven effective. 



The approach used to design the system is 



the 



J . 



Iterative Design Approach or Staged Development Approach. 
The present design of PQWCP system is the first iteration, 
the Commercial Procurement function. After receiving user 
feedback from the initial system, the second iteration will 
start. This system will be expanded into a general purpose 
Decision Support Systems (DSS) to be used in the procurement 
activities of foreign country procurement offices. Such a 
system with the DSS generator 1 database 1 will provide an 
excellent decisionmaking tool as well as providing support 
for.-, routine operation of the Management Information System, 
for example financial management and tracking of contracts. 

4. Implementing the system required extensive efforts , 
especially in building the database which is the foundation 
for any other improvements to the system. The most difficult 
problem to overcome is the data entry phase for initial 
loading of the database. The willingness and support of the 
POW Director and specialized officers are essential for the 
success of this system. 

5. The use of PC/FOCUS provides fully compatibilty 
with the mainframe FOCUS and its capability to handle 
external files (not produced by FOCUS) will give the system 
flexibility to interface with other systems. 

6. As long as increases in microcompu t er technology 
continue, no limits are foreseen for the system capability, 
including multi-user and wide area communication with Cairo. 
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B. 



RECOMMENDATIONS: 



The objectives of the thesis nave been successfully 
completed. Learning about computer systems development 
methodology without application is like taking swimming 
lessons without actually swimming. The process of developing 
PQW was a real challenge. The following remarks about the 
system can be made: 

1. At the beginning, the actual size of the system 
effort was under estima ted which is a common a pitfall in 
system development. 

2. Walking through the details of the system using the 
structured systems analysis technique enforced the developer 
to address and describe more details about the system which 
spent more time and efforts than required within the time 
limitation of doing the thesis. However this technique has 
been proven succeeded in designing a roubist information 
systems in the real world situation. 

3. Combining building the DSS generator with the 
iterative design approach of DSS leads to a conflict in 
developing system r e q u i r em e n t s . The DSS generator needs a 
detailed and complete systems analysis to build the data 
dictionary down to the primitive level of detail. (Data 
elements that cannot be divided any more and processes that 
cannot be exploded any more.) On the other hand, the 
iterative design approach requires building DSS with short, 
rapid feedback from users to ensure that development is 



proceeding correctly. This may be very difficult if we start 
from a manual system like POW. To solve this conflict in the 
real world probelms, developing the DSS (either the 
iterative or the complete DSS) should be started from a 
database foundation. 

4. Using software development tools is very important, 
especially in building the DFD and the system data 
dictionary. 

5. Importance of documentation is addressed during the 
systems development. Self documentation and giving data 
elements meaningful names are very important in designing 
the system . 

6. Deep understanding of the system is hard to obtain 
unless you walk through the system. The DFD gives the 
developer the opportunity for self feedback and to readjust 
the system as necessary. 

7. This thesis can be used as a requirements document 
for any future development of a DSS for the Egyptian Armed 
Forces . 

Based on the learning experience dicussed above, the 
following recommendations can be made for the future 
enhancements of the POW system: 

1. It is strongly recommended that efforts continue 
on designing a usable DSS for POW. The cost-benefits 
of using the system is extremely favorable. 

2. Utilization of PC/FOCUS and its utilities associated 
with the structured system analysis technique are 
most suitable for the iterative design approach we 
used. The recommendation is to purchase the software 
for implementing and using the system. 
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j. The most suitable hardware for implementing the 

system are: 

a. IBM-XT or IBM-AT m i c r o c om p u t e r (IBM-AT is 

preferable because its faster than IBM-XT) with 
640 KB and at least one floppy diskette derive 

b . Hard Disk 

c. IBM Enhanced Graphic Adapter to allow using 
Arabic Language facilities in PC/FOCUS, 

d . Co 1 o r Mon i t o r ' 

e . Matrix Printer 

f • Power Supply and Accessories 
4 . Future Recommendation 

It is recommended to advance the implementation of 
the proposed system until the third iteration, at least. The 
first and second' iterations will emphasize building the DSS 
generator and giving acceptance by POW users. The third 
iteration will use the PC/FOCUS capability to build other 
two modules of the DSS: a model management subsystem which 

allows analytic capabilities to be added to the system like 
evaluation of alternatives and formulating relationships 
between variables in a way that permits the creation of 



simulation 


or 


"what 


if" 


models, 


and 


a dialog management 


component 


which 


can 


be 


tailored 


to 


POW functions with a 


complete 


help 


facility 


to give 


users 


of the system full 



capabilities 


without prior 


knowledge 


in computer 


programming . 


PC/FOCUS has the 


facilities 


to build both 


components . 
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APPENDIX A 



DFD CONVENTIONS 

Structured Systems Analysis (SSA), as presented in the 
reference " Structured Systems Tools and Techniques " by Gane 
and Sarson [Ref. 3] is a technique used to perform systems 
specification. Data Flow Diagrams (DFD) are used to picture 
the system and the Data Dictionary is used to define the 
data elements and the data structure. Processing logic pres- 
entations, such as decision tables and structured English 
are used to precisely specify processing sequences in terms 
that are understandable to the user and developer. For the 
commercial procurement subsystem, the SSA specification is 
refined to the detailed design level. For the other sub- 
system we stop at the software requirement specification. 

A. DFD SYMBOL CONVENTIONS 

The logical Data Flow Diagrams are very important for 
picturing the system to the user; they provide a blue print 
of the system. This way of presenting the system provides a 
communication tool between the systems analyst and the user 
on one side, and between the systems analyst and the soft- 
ware programmers on the other side. The DFD is designed to 
present the processes in a logical, top down approach, 
independent of physical location or physical implementation. 
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This technique emphasizes the data flow through the system 
providing a comprehensive understanding of the system and 
resulting in the Data Dictionary the most valuable output in 
systems development. 

As an example, consider the following simple function in 

DFD : 



check the‘m against 


a 


file of 


items 


available , check 


against some file 


to 


see that 


the customer credit is 


okay, and cause the 


items 


ordered 


to be 


sent out with an 



invoice . 



We could show this logical DFD as follows: 



BOOK DATA 



OUST. 



Orders 



Invoices 



(with booksK 



Rounded 
rectangle 



credit 

status 

I I CUSTOMER DATA 



Figure 1 Logical Data Flow Diagram (DFD)' 

Only four' symbols are used to picture this simple 
function. The flow of data may physically be contained in a 
letter or an invoice, in a telephone call, from program to 



program, via satellite datalink or anyplace where data flow 
from one entity or process to anther. a process may 
physically be a room full of operators receiving mail 
orders, getting money from an ATM machine, or a combination 
of manual and automated activities. A data store can be a 
rotary card file, a record book, a microfiche, a filing 
cabinet, even a table in core, or magnetic file on tape or 
disk. Using the four symbols enable us to draw a picture of 
system without committing ourselves to how it will be 
implemented. We started with a very general DFD and then we 
could go to the details step by step. Figure 2.2 shows the 
expansion of the previous DFD. [Ref. 33 




Figure 2 Expanded Logical DFD 

We continue the expansion of DFD in a top down fashion 
until we get to the elementary process level, that can't be 
divided any more . 

Tracing the DFD is very important to understanding the 
system. It is advisable for the systems analyst to present a 
walk through of the DFD with users at the beginning, so the 
user can get the concept of DFD. The preferable way to 
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walkthrough the DFD is to start from the external entities 
and describe the input data flow lines and each process in a 
logical sequence, and then follow the output data flow lines 
until exits or is stored somewhere in the DFD. 

B. SYMBOLS DESCRIPTION 

1 . External entities 

S 

The most usually logical classes of things or 
people which represent a source or destination of 
transactions, e.g, vendors, officers, tactical units, 
Armament Authority, or Department. If our system accepts 
data from another system or provides data to it, that other 
system is an an external entity. 



Double 

Square 



ExtemaJ Entity 



Figure j External Entity 



An entity is identified by lower case letters in the upper 



left hand corner for reference. 



2 . 



Data flow 



Data flow is symbolized by an arrow, figure 2.4. 
Each data flow may be thought of as a pipe down which 
parcels of data are sent. The data flow may be referenced by 
giving the processes, entities, or data store at its head 
and tail. 



flrroa 

(Data Flov} 






Figure 4 Data flow symbols 



3 . Process 

The process can be symbolized by an upright 
rectangle, with the corner rounded, optionally divided into 
three areas, Figure 2.5. 



Identification of the Processes 



Description of the function 



Physical Location where 
Performed w 



M . Rout inn^ 



Route 

the 

Proposals 
P0W ) 



Figure 5 Process 
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4. 



Data store 



Data store can be symbolized by a pair of horizontal 
parallel lines, closed at one end (Figure 2.6). Each store 
can be identified by a M D" and an arbitrary number n in a 
box at the left end for easy reference. 



c 

! 



Open ended rectsng ie 



Figure 6 Data store 

The external entities and the data stores may be 
duplicated to prevent interconnections between aata flow 
lines (Figure 2.7). In the external entity, multiple diag- 
onal lines are used to indicate that the external entity is 
pictured more than once in the same DFD. 

Occurs one time 

— 



Occurs tvo 
times 





Occurs three 












times * 


/ 

/2 




\\ 







Figure 7. Duplication of the External entity 



i ;i n 



In the data store, multiple vertical lines are used 
to indicate that the data store is pictured more. than once 
in the same DFD, Figure 2.8. 



Occurs one time 



0ccure3 tvo times 




Occurs three times 



Figure 8, Duplication of Data Store 

The information presented , so far is sufficient to 
understand the DFD. The second step is to put detailed 
information about the DFD in a Data Dictionary. 

C. THE DATA DICTIONARY 

The data dictionary keeps all the details and contents 
about the data flows, data stores, and processes. The 
information we need to keep in the data dictionary is 
classified into three levels: 
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1 . Data Elements 



These are the pieces of data that it is not meaning- 
ful to decompose further for the applicated at hand; e.g, 
date, product number, etc. 

2 . Data Structures 

These are made up of data elements, or of other data 
structure, or a mixture of both, for example: 

VENDOR 

VENDOR-ID 

VENDOR-NAME 

FIRST-NAME 

LAST-NAME 

PHONE 

AREA-CODE 

NUMBER 

EXTENSION 

BUSINESS-START-DATE 
BUSIN ESS- ASSET- VALUE 
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3 . Data Flow and Data Stores 



Data flows are paths or "pipelines" along which data 
structures travel. Data stores are places where data struct- 
ures are stored until needed. In other words, data flows are 
data structures in motion, data stores are data structure at 
rest. 

The data description hierarchy can be represented as 
follows . 




Figure 9 Data description hierarchy 
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APPENDIX B 
MODULES LISTINGS 



A. POWMAINM : 

SET PAUSE = OFF 
SET MSG=ON 
-TOP 

LET ! 1 =HELP 

-CRTCLEAR 

-BEGIN 

-SET &REPLAY=0; 

-TYPE 

-CRTFORM 

— I! 

_ If 

WELCOME TO 

_ 

POW DECISION SUPPORT SYSTEM 

— If 

— 11 ' 

-" MAIN MENU 

_ ft 
_ If 

— ft 

-" DATA ENTRY / UPDATE / DELETE 1 



-" CREATE NEW FILE DESCRIPTION 2 

-" GENERATE REPORTS 3 

-" EXIT 4 

-" HELP 5 

_ ft 



-" SELECT (12345) <& R E P LA Y <77 

— II 
_ If 



&REPLAY 


EQ 1 GOTO 


AUTO 






ELSE IF 


& RE P LA Y 


EQ 


2 


GOTO 


FTALK 


ELSE IF 


&REPLAY 


EQ 


3 


GOTO 


TTALK 


ELSE IF 


&REPLAY 


EQ 


4 


GOTO 


EXIT 


ELSE IF 


& RE PL A Y 


EQ 


5 


GOTO 


HELP ELSE GOTO NOPE 



-AUTO 

EX POWAUTO 
-RUN 

-CRTCLEAR 
-GOTO BEGIN 
-FTALK 
FILE TALK 
-RUN 
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-CRTCLEAR 
-GOTO 3EGIN 
-TTALK 
TABLE TALK 
-RUN 

-CRTCLEAR 
-GOTO BEGIN 
-HELP 

EX POWHELP 
-RUN 

-CRTCLEAR 
-GOTO BEGIN 
-NOPE 

-TYPE &REPLAY IS NOT A VALID OPTION 

-... PLEASE REVIEW OPTIONS AND RE-ENTER 

-GOTO BEGIN 

-quit 

-EXIT 

B. POWAUTO: -[Ref. 9] 

SET PAUSE=OFF 
SET MSG=OFF 
-TOP 

-CRTCLEAR 

-IF &1. EXIST EQ 0 GOTO NONAME; 

-SET &FNAME=41; 

-GOTO GOTNAME 
-NONAME 

-SET & F N AM E = ' ' ; 

-START 

-CRTFORM 

ii 
ii 

WELCOME TO THE PC/FOCUS 

ii 

AUTOMATIC DATA MANAGEMENT SYSTEM 

ii 
n 
ii 
ii 

PLEASE ENTER THE NAME OF THE FILE " 

n 

YOU DESIRE TO MODIFY: " 

ii 

<T . &F N AME <77 " 

ii 
ii 

PLEASE WAIT 

THE MAIN MENU IS NOW LOADING 



-TYPE 

-TYPE 

-TYPE 
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-GOTNAME 

-IF &FNAME. LENGTH GT 3 GOTO 3ADNAME; 

-SET &FF = &F NAME !! ’.MAS’ ; 

-DOS STATE &FF 

-IF &RETCODE NE 0 GOTO 

NONAME ; 

-SET & REP L Y = ' ' ; 

-SECTION 1 
-CRTFORM 

_» it 



_ ii 



AUTOMATIC DATA MANAGEMENT FILE < D . & F N AM E <77 " 

ii 



-" PLEASE SELECT A PROCESS 

_ ii 



it 

ii 



_ n ii 

-" 1 ADD NEW RECORDS " 

-" 2 ADD NEW RECORDS, UPDATE EXISTING RECORDS " 

-" 3 UPDATE EXISTING RECORDS ONLY " 

-" 4 DELETE RECORDS " 

— ii it 

-" 5 RETURN TO MAIN MENU " 

— ii ii 

— " " ii 

-" ENTER YOUR SELECTION (12 3 4 ) <«5cREPLY <77 " 

— it it 



_ ii 



ii 



-IF & RE PLY EQ 1 GOTO ADD ELSE IF &REPLY EQ 2 GOTO ADDUP 
-ELSE IF &REPLY 

- EQ 3 GOTO UP ELSE IF & RE PL Y EQ 4 GOTO DEL ELSE 

- IF & R E PLY EQ 5 GOTO EXIT 

- ELSE GOTO NOPE; 

-ADD 

MODIFY FILE &FNAME 
CRTFORM 

ii it 



" AUTOMOD OPTION #1...ADD NEW RECORDS " 

ii n 

" 'TAB' FOR NEXT FIELD 'ENTER' TO TRANSMIT DATA " 

" ' F 7 ’ FOR PRIOR SCREEN ' F 8 ’ FOR NEXT SCREEN " 

" ' F 3 * TO RETURN TO PREVIOUS MENU " 

ti ii 

CRTFORM 

« 

MATCH * 

KEYS 

ON NOMATCH TYPE 

it ii 

RECORD ACCEPTED .... ENTER NEXT RECORD " 

ON NOMATCH INCLUDE 
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ON MATCH TYPE 

it ii 

RECORD ALREADY EXISTS .... REJECTED 

LOG DU PL MSG 

OFF 

DATA 

END 

-TYPE PLEASE WAIT 

-TYPE 

-TYPE PC/FOCUS IS LOADING YOUR FILE 

-RUN 

-TYPE PLEASE WAIT 

-TYPE 

-TYPE PC/FOCUS IS UPDATING YOUR FILE 

-GOTO SECT ION 1 

-ADDUP 

MODIFY FILE &FNAME 
CRTFORM 

" AUTOMOD OPTION It 2 . . .ADD/UPDATE RECORDS 

It II 

" 'TAB* FOR NEXT FIELD 'ENTER' TO TRANSMIT DATA " 
" ' F 7 ' FOR PRIOR SCREEN 'F8' FOR NEXT SCREEN " 
" . * F 3 ' .TO RETURN TO PREVIOUS MENU " 

ii it 



CRTFORM * 

KEYS 

" ' DEPRESS ENTER 



MATCH * 

KEYS 

ON MATCH TYPE "UPDATING EXISTING RECORD " 
ON NOMATCH TYPE "ADDING NEW RECORD" 

ON MATCH/NOMATCH CRTFORM T.* NONKEYS 
ON MATCH UPDATE 

* 

ON NOMATCH 
INCLUDE 

LOG NOMATCH MSG OFF 

DATA 

END 

-TYPE PLEASE WAIT 

-TYPE 

-TYPE PC/FOCUS IS LOADING YOUR FILE 
-RUN 

-TYPE PLEASE WAIT 

-TYPE 

-TYPE PC/FOCUS IS UPDATING YOUR FILE 

-GOTO SECT ION 1 

-UP 

MODIFY FILE &FNAME 



156 



CRTFORM 



n 



m 



= -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- .-ti 

AUTOMOD OPTION #3... UPDATE EXISTING RECORDS ! 



'TAB' FOR NEXT FIELD 'ENTER' TO TRANSMIT DATA 
' F7 ' FOR PRIOR SCREEN 'F8'FOR NEXT SCREEN 
' F j ' TO RETURN TO PREVIOUS MENU 



CRTFORM 

KEYS 

n 

" DEPRESS ENTER " 

MATCH * 

KEYS 

ON NOMATCH TYPE 

" RECORD DOES NOT EXIST .... ENTER NEXT RECORD " 
ON MATCH TYPE 

" ENTER NEW VALUES " 

ii it 

ON MATCH CRTFORM T.* 

NONKEYS 

ON MATCH UPDATE 

* 

LOG NOMATCH MSG 
OFF 

DATA 

END 

-TYPE PLEASE WAIT 

-TYPE 

-TYPE PC/FOCUS IS LOADING YOUR FILE 

-RUN 

-TYPE PLEASE WAIT 

-TYPE 

-TYPE PC/FOCUS IS UPDATING YOUR FILE 

-GOTO SECTION1 

-DEL 

MODIFY FILE &FNAME 
CRTFORM 

II 

" AUTOMOD OPTION #4... DELETE EXISTING RECORDS 

II 

" 'TAB' FOR NEXT FIELD 'ENTER' TO TRANSMIT DATA 
" ' F7 ' FOR PRIOR SCREEN ’ F 8 ’ FOR NEXT SCREEN 

" ' F3 ' TO RETURN TO PREVIOUS MENU 

II 



CRTFORM * 
KEYS 

II II 



MATCH * 
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KEYS 

ON NOMATCH TYPE 

tf If 

RECORD DOES NOT EXIST .... ENTER NEXT RECORD ..." 
ON MATCH TYPE 

II If 

" RECORD DELETED . . . . " 

ON MATCH 
DELETE 

LOG NOMATCH MSG 
OFF 
DATA 
END 
-TYPE 
-TYPE 
-TYPE 
-RUN 
-TYPE 
-TYPE 
-TYPE 
-GOTO 
SECTION 1 
-3ADNAME 

TYPE INVALID FILE NAME (EXCEEDS 8 CHARACTERS) 

-GOTO 

TOP 

-NOPE 

-TYPE &REPLY IS NOT A VALID OPTION 
-....PLEASE REVIEW OPTIONS AND RE-ENTER 
-GOTO SECTION 1 
-NONAME 

-TYPE FILE NAMED &FNAM E | ! .XXX CANNOT BE LOCATED... 
-PROMPT &REPLY. RE-ENTER FILE NAME OR 

QUIT . 

-GOTO SECTION 1 
-EXIT 

C. POWDIC: 

SET PAUSE = OFF 
SET MSG=OFF 
-TOP 

-CRTCLEAR 

-IF &1. EXIST EQ 0 GOTO NONAME; 

-SET &F N AM E = & 1 ; 

GOTO GOTNAME 
-NONAME 

-SET & F N AM E = ' ' ; 

-START 

-TYPE THIS IS THE AN ONLINE HELP SCREEN 
-CRTFORM 



PLEASE WAIT 

PC/FOCUS IS LOADING YOUR FILE 
PLEASE WAIT 

PC/FOCUS IS UPDATING YOUR FILE 



TYPE 
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ONLINE HELP SCREEN 



_ ft 



_ It 

INFORMATION ON FOCUS <1> 

INFORMATION ON FOCEXECS <2> 

DICTIONARY MAINTENANCE <3> 

QUIT < 4 > : 

_ ii 
_ ii 
_ ii 



-PROMPT &SELECT. WHAT IS YOUR CHOIC ? 
-END 



D. POWHELP: 

-CRTC'LEAR 

-BEGIN 

-SET OEPLAYrO ; 

-TYPE 

-CRTFORM 

_ ii 
_ ii 

POW 

_ II 

-" HELP SCREEN 

_ ii 
_ ii 
_ ii 
_ ii 



it 



it 



_ ii 



- " 1. System Description 

2. Online Help 
-" 3 . Ex i t 

_ ft 

— H 

-" SELECT (123 ) < & R E P L A Y <77 



-IF &REPLAY EQ 1 GOTO SYSDESC 

ELSE IF &REPLAY EQ 2 GOTO ONLINE 

ELSE IF &REPLAY EQ 3 GOTO EXIT 

ELSE GOTO NOPE; 

-ONLINE 
EX POWDIC 
-RUN 

-CRTCLEAR 
-GOTO BEGIN 
-SYSDESC 
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-TYPE 

-GOTO BEGIN 
-NOPE 

-GOTO BEGIN 

-quit 

-EXIT 



*»* WILL BE DEVELOPED 1 ATE R 



# * * 
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APPENDIX C 



DATA DICTIONARY 



The following are the list of DFD Elements in the Exist- 
ing system as we described it in the previous DFD (Commer- 
cial Procurement): 

A. EXTERNAL ENTITIES 

NAMES ABBREVIATION IDENTIFICATION 



Armament Authority AA a 
Vendor V b 
Bank B c 
Defense Security Assistance 

Agency DSAA d 
Central National Bank of 

Egypt CNBOEG e 
Fright Forwarder FF f 
Independent Market Association IMA i 
United State Security and 

Assistance USASAC j 



B. PROCESS: 



PROCESSES ABBREVIATION 


IDENTIFICATION 


RFP Function 


RFPF 


1 


Prepare & issue the RFP's 


P I RFP 


1 . 1 


Register RFP & Rout to 






Specialized Officer 


RRTSO 


1.1.1 


Rev iew RFP 


R RFP 


1.1.2 


Select Vendor List 


S VL 


1 . 1 . j 


Prepare Copies of RFP 


PCORFP 


1.1.4 


Check Vendor Qualification 


CVQ 


1.1.5 


Add New Vendor to VL 


ANV 


1.1.6 


Receive Proposals From Vendors 


RPFV 


1 . 2 


Register Proposals and route 






to the Specialized Officer 


RPTSO 


1.2.1 


Review and scan Proposals 


RASP 


1.2.2 


Prepare Summary Reports 


PS R 


1.2.3 


Check Vendor Qualification 


CVQ 


1.2.4 


Send Proposals To AA 


SPTAA 


1 . 3 


RFC Function 


RFCF 


2 


Process the RFC 


PRFC 


2. 1 


Rgister & Route 


RAR 


2.1.1 


Check RFC for Completness 


CRFC 


2.1.2 


Determinr the Source of Fund 


DSOF 


2.1.3 


Prepare the contracting and 






Implementation Plan 


PCIP 


2.1.4 
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Form Negotiation Team FNT 
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